I've prepared two definitions to illustrate the issue:
- The first, available here, is a simple case with a small data set
- The second, available here, is a larger data set that may take longer to load/open
The expected behaviour is that adding a sub category filter would cause the OSMComponent to filter that data to items that match. This happens with multi-point items (ways?) but does not seem to happen with single point items. This makes it much more difficult to extract/classify points of interest - e.g. types of 'craft' shops (as illustrated in the definitions).
Looking at the code paths while using the Budapest data set, unorderedWays contains 112 items so the filtering of allPoints by the parent "craft" category appears to work. I'm still getting a handle on the code, but it looks like only the <way> tags go through a subsequent filtering process to match their subcategory type in line 379 of Processors.cs. There doesn't seem to be anything special about the data used in the two definitions linked above, so I'm assuming this behaviour occurs in all other instances.
I'm not sure if this was a regression or if this was never how Elk worked. Regardless, please let me know if you would be interested in a PR to address this issue / add this feature. I'll likely prepare a change to this effect as part of getting to know the code.
Thanks again for your time and your work with Elk! Please let me know if further details would be helpful.
I've prepared two definitions to illustrate the issue:
The expected behaviour is that adding a sub category filter would cause the
OSMComponentto filter that data to items that match. This happens with multi-point items (ways?) but does not seem to happen with single point items. This makes it much more difficult to extract/classify points of interest - e.g. types of 'craft' shops (as illustrated in the definitions).Looking at the code paths while using the Budapest data set,
unorderedWayscontains 112 items so the filtering ofallPointsby the parent "craft" category appears to work. I'm still getting a handle on the code, but it looks like only the<way>tags go through a subsequent filtering process to match their subcategory type in line 379 ofProcessors.cs. There doesn't seem to be anything special about the data used in the two definitions linked above, so I'm assuming this behaviour occurs in all other instances.I'm not sure if this was a regression or if this was never how Elk worked. Regardless, please let me know if you would be interested in a PR to address this issue / add this feature. I'll likely prepare a change to this effect as part of getting to know the code.
Thanks again for your time and your work with Elk! Please let me know if further details would be helpful.