[talk-au] Non-Contributed Information Related to Ways?

Andrew Harvey andrew.harvey4 at gmail.com
Thu Jul 9 04:56:44 UTC 2020


On Thu, 9 Jul 2020 at 11:02, Andrew Hughes <ahhughes at gmail.com> wrote:

> Hi Again All,
>
> We would like to investigate how we should store information which is
> related to ways given the following:
>
> + Some specific information we are looking to store is to meet our needs.
> We do have every intention to offer and promote the data through open
> source. However, they're fit for our purposes and won't be a popular item.
> So, I don't see us contributing these back directly...
>

> + Some of the information we are looking to store will need to be authored
> in accordance with legal requirements (basically, the person who says "You
> can drive a Sherman tank on this road" is allowed to do so, and not some
> unauthorized individual contributing via OSM). So in this case, we need to
> control who can create the related information.
>
> To me the above seems like "private tags", happy to discuss that in
> isolation (and not really sure how/if that can be done). However...
>

As a rule of thumb if it's not verifiable (by the public) and tightly
linked to your internal operations I'd probably say OSM isn't the best
place for that data. But you can still store this in your own database and
link it to OSM.

+ We may need to "split" a single road segment into 2 or 3 segments to
> accurately model our relationships geographically - this would be
> contributed back to OSM. If there is something like a culvert (with a
> weight limit) half way along the road that won't support the tank then, yes
> we can split the road and tag the middle section as a Culvert and maybe the
> maxWeight and that would be contributed back to OSM and we would get our 3
> segments + culvert & weight tags. But what if that mid segment is only
> needed as a segment for our purposes.. like "The adjacent property owner
> complained to the council about noise, so you can't drive your Sherman tank
> here"?  In which case... we could go split the road into 3 and contribute
> back, but others will see no reason as to why this was done? and I don't
> know what happens then? If I saw that, I'd think they should be dissolved
> back to 1 segment. I'd consider "area" based relationships, but they are
> really tricky around intersections and prone to failure. Particularly when
> the geometry is subject to so much change (i.e. turn out lane added...)
>

If you're splitting the way because different tags (like
https://wiki.openstreetmap.org/wiki/Key:maxweight) apply to different
segments that's fine, but if it's just to suit your private/internal use
case then no.

To give an example of something I'm more familiar with, Mapbox have a
Mapbox Traffic Data product of live and historical traffic speeds. This is
referenced against the OSM road network but published this in two alternate
formats:

1. OpenStreetMap node IDs. They use the start node ID + end node ID +
speed, then data consumers download OSM find the start/end node IDs and now
have the private speed data referenced against the OSM road network. Now
OSM node ids change all the time so your process needs to be aware of that
and is limited that the OSM way might not have nodes exactly where you want
it, so it's only good for some use cases.
2. OpenLR strings. http://www.openlr.org/ in the most simple use case
OpenLR strings are essential lat/lon start/end points, then data consumers
go and match those GPS point back to the OSM road network and connect it to
find the road segment from OSM that the OpenLR string references.

Of course OSM does change over time so you'd probably want to refer to a
specific timestamp snapshot of OSM.


>
> Plus (and probably less complicated)...
> + We need to detect/flag when our "private" information has a
> broken/orphaned "relationship" with OSM (ways). Because a way was deleted,
> split, merged... e.t.c... then we can repair the relationship.
>

That's right, you'd need to have some process in place to watch for that
and if something changed in OSM you might want to review that your
references to OSM are still what you expect.


>
> Given all of the above, I would really appreciate any insight/suggestions
> anyone has.
>
> Sorry if my explanation isn't the best... I hope it made sense.
>
> Thanks for reading,
> A Hughes.
>
> _______________________________________________
> Talk-au mailing list
> Talk-au at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20200709/a1677664/attachment.htm>


More information about the Talk-au mailing list