logant / elk Goto Github PK

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.

Issue related to the loading of the gdal dll in grasshopper.
Every .dll file is located within the component folder of grasshopper plugin, however "TOPO" doesn't compute the result.