Finding bodies of water out of OSMshape

Over on the Rhino Discourse, a user is experiencing problems with getting bodies of water out of ELK when using bigger osm files. I thought I'd try it in Gismo.

A few observations:

First of all, OSMshape pretty much always throws the error:

The component generated invalid shapes data.
To fix this issue, simply rerun the component (set the "_runIt" input to "False", and then again to "True").

Toggling from True to False and back to True doesn't work.

Secondly, when I set the shapeType to 1 (polylines), I get roads but also houses and lakes.

Finally, trying to filter the shape output to e.g. only things that are tagged natural = water on the map, the OSMsearch doesn't find anything. I'm using OSMtag with "_requiredKey" set to "natural" and "requiredValues_" to "water" to create a requiredTag input for OSMsearch.

What am I doing wrong?

Simple sample attached.

Attachments:

Gismo-Natural-Water.gh, 52 KB

Replies to This Discussion

Permalink Reply by djordje on January 14, 2018 at 3:56pm

Hi Wim,

Thank you for opening the topic!

On: "The component generated invalid shapes data." warning message.
This is a bug in MapWinGIS, not in Gismo.
The way it works on my PC, is that I always wait for a couple of seconds (say 10) between setting the Boolean Toggle to False and setting it again to True.
If you keep getting the same message, even after waiting for those 10 seconds, Try turning off one of the "OSM shapes" components, in case it has been turned on, and then try to turn on the "OSM shapes" component which raises the upper warning message.
If it still repeats, try shutting down Rhino, and running it again. Then run first the component which raises the warning.
Never leave the _runIt inputs of "OSM Shapes" components to "True" when you are opening the .gh files. Set them to "False" and rerun them to "True" once the .gh file is opened.

To stop going through all of this over, and over, you can internalize the "OSM shapes" outputs, once all of those components have been ran properly.

In general, "shapeType_" = "polylines" should contain non closed polylines. But as you noticed sometimes it can contain closed polylines, but to a lesser degree. I think this has to to do with the way OGR driver which MapWinGIS uses deals with OSM data. "shapeType_" = "polylines", should contain OSM's "way" elements, which sometimes can be closed as well, but limited to 2000 points.
In defense of all of this, I can only say that OGR is probably the best open-source OSM to SHP file converter, so I guess we can't get better than this, if we are using SHP file readers, the way Gismo does.

From my limited knowledge, it can be that some online OSM to SHP services (like extract.bbbike.org, which you mentioned), also use the same OGR drivers.
Have in mind that what sometimes looks like a house floor plan, may not be that. It can be that the same house floor plan is located in "shapeType_" = "polygons" but labeled as "building=yes/...", while the shape you see is some relation, but not labeled as "building=yes/...".
Still I definitively see some closed forest areas in "shapeType_" = "polylines", so I have to agree with your observation. It makes the "OSM shapes" component's input description a bit inconsistent, but that's how OGR works, and we can't change it.

For finding rivers, you can use the Gismo "OSM objects" drop down list.
It is using "waterway" as "_requiredTag" and no value for "_requiredValue" (meaning any will be accepted).

In the end, the "radius_" input can greatly determine the final shape of extracted data. Good example are wide rivers, like Seine. If you "radius_" is a bit smaller, then it can be that you won't cover much of the river, so you will not be able to extract its riverbanks. This is why I increased the radius in your definition to "600". This is the result: