On Thu, 9 Jul 2020 at 11:02, Andrew Hughes <ahhug...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-au >
_______________________________________________ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au