Almost forgot about this. clay_c and I weren't sure about this since we had two different approaches that both seemed suspect.
I've been using layer tags where possible all along. I think there's definite agreement there. If I overlap nodes (or within some determinedof two differently-layered railways or roadways, JOSM considers it an *error* of overlapping nodes. If I have the railways or roadways share nodes, JOSM *warns* me of overlapping ways. Considering that routing application that might be confused by overlapping nodes, I should definitely change the junction. With overlapping nodes, I also have overlapping switches (which I never tagged as switches) that wouldn't be mappable anyway. There may come a time I have data on train track centerlines in NYC, perhaps something highly accurate like state plane coordinates. Hopefully my FOIA journeys are successful: I want New York to be the model of underground railway data in OSM. (If there are any MTA insiders [or those in the transport industry] who are familiar with mapping documents, please tell me about documents that I can try to FOIA) I find it weird that I would have to manually offset points when I can just plug in the state plane coordinates and my work is done. We wouldn't necessarily be mapping for the renderer, but rather something odd: mapping for the validator? They would be overlapping nodes physically located at the same spot, calculated from hypothetical, authoritative source coordinates. Proper editing of these tracks would involve filtering out layers to work on the correct layer as needed. It's intimidating for someone not familiar with this situation. clay_c chose to space out rails by a whole foot, which seems rather excessive. Spacing out can be rather weird for any editor, so hopefully people will tend not to touch it unless they really know what they are doing. I feel like whatever solution we choose is going to be really "weird", so we have to bite the bullet. I hope we settle on solution 2, ("Duplicate nodes with identical positions") but we'll need some changes to some of the mapping validators to not throw an error for nodes attached to ways on different layers. -- May 16, 2020, 05:36 by m...@nguyen.cincinnati.oh.us: > Vào lúc 10:28 2020-05-05, Michael Reichert đã viết: > >> Using the same nodes (like mapping to adjacent landuse polygons) breaks >> routing because routing engines would allow trains to switch between the >> levels. Using duplicated nodes at the same location is likely to trigger >> quality assurance services and therefore mappers trying to "repair" it >> by merging them. Using two identical geometries in straight sections >> with nodes at different locations, will likely provoke the same as >> duplicated nodes. >> > > Just as a double-decker bridge requires layer tags on each deck, so would a > double-decker subway tunnel, whether the ways are coincident or offset by > some arbitrarily small amount. Adding layer tags, as suggested in [1], would > likely suppress any validator warnings about coincident ways. But it's true > that mappers could still be confused by coincident ways if editors don’t > provide intuitive ways to navigate among them. > >> Regarding option 2: GraphHopper assembles its routing graph by relying >> on the node IDs in OSM. It would not suffer from using this option but I >> doubt that it is safe for the future. If OSM adopts to drop its 64 bit >> node IDs in favour of the location (32 bit latitude + 32 bit longitude), >> such cases will cause difficulties. >> > > This is an intriguing notion I had not come across before. Has it ever been > seriously considered? It seems to me that distinguishing nodes only by their > coordinates would be tantamount to merging all coincident nodes everywhere, > which we probably would never allow as part of a mechanical edit, much less a > history-less database schema update. (For one thing, everyone who dislikes > joining borders to roadways would be appalled to see just about every CDP > boundary consistently joined that way.) > > [1] https://lists.openstreetmap.org/pipermail/talk-us/2020-May/020015.html > > -- > m...@nguyen.cincinnati.oh.us > > > _______________________________________________ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us >
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us