In some areas where the National Hydrography Dataset (NHD) has been imported, the rendering of the data is less than desirable. I am not sure if this is something that should be fixed in renderers or in the data.
The issue is that the NHD includes polygons for waterbodies in one data set, and stream lines in another data set. In the streams data set, artificial flow connectors have been introduced to provide connectivity through the waterbodies (e.g. lakes). When the data is rendered in the default OSM Mapnik tiles, the artificial stream connectors are being rendered on top of the waterbody polygons. Here is an example: http://www.openstreetmap.org/?lat=45.0361&lon=-93.6592&zoom=14&layers=M Here is an example of one of the ways representing an artificial connector: http://www.openstreetmap.org/browse/way/60497444 Note that with the tags assigned, there is no way to determine if this way represents an artificial connector or not. Is there a consensus (not that there ever is in OSM...) on what the best solution for this is? I see a couple of scenarios. They depend partially on what the purpose of the NHD import is. 1. If the stream data has been imported to allow network creation and stream navigation, the connectors should stay. (Kayaking directions by MapQuest?!) If they are only being imported for the purpose of providing a high-res water background layer, they could probably be removed. Should they be removed? 2. If the connectors should stay should tickets be submitted to renderers to somehow put the artificial connectors 'under' the waterbodies based on existing tags? 3. If the connectors should stay, should a tag be added based on the feature's FCODE to mark these connectors so that the renderers can have an easier time dealing with them? I don't know if this is a hydro-specific tag, like waterway=artificial_connector or if it is just done through the assignment of layer tags (could get messy). I am sure that others have thought about this. Since this is a nation-wide import, it would be great to have a consistent approach to this. David. _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
