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
