On Tue, Dec 10, 2019 at 6:35 PM Pieter Vander Vennet <pieterv...@posteo.net> wrote:
> Hello Jo, > > Thanks for the informative answer which offers a very informed view and > for your many contributions. > > I'll break it up onto multiple subtitles, as there are some sub-topics > emerging. > > *Tagging scheme* > > I'd actually go for `cycle_network=BE:cycle_highway`, as cycle_network > normally has a country prefix. Because most (all?) of them are already > tagged, we could simply update the tagging all at once. I'll do that next > week, unless a better proposal or good reason not to is raised. > Sounds good to me > > *state=proposed and ground truth * > > This is a very good semantic question. Officially, we could only lift the > state=proposed when all the signposts are present. Alternatively, we could > have the relation only containing the parts that are already cyclable, and > having another relation containing the unfinished parts, but I feel that > this is a lot of work for little to no gain. If a segment has > 'highway=proposed' on it, well, the meaning of that is quite clear. So, > practically speaking, how it is done now is quite good. > highway=proposed, proposed=cycleway works well for ways that don't exist yet. state=proposed somewhat less well. One of my goals is to create route relations that don't have gaps in them. To reach that in the official ones, we need those highway=proposed ways, no problem there. My other goal is to show cyclists what itinerary they can already use today to bridge the missing parts to get from the start of the intended Fxx to the end. In that relation I also want to have no gaps, hence the duplication of ways for those parts that are already realised. My solution would be to have many subrouterelations, but that would become somewhat more complex. > *Alternative routes* > > The alternatives pose a different problem. I think that the best solution > would be to have a single extra relation for each alternative leg - but > only containing the differing parts, which would avoid having cycleways > which are part of both the official and alternative ways. > > For tagging, I find it however hard to add a > `cycle_network=BE:cycle_highway` to it. Maybe we could opt for > `cycle_network=BE:cycle_highway:unofficial` or > `cycle_network=BE:cycle_highway:alternative`? It should be noted however > that these will never be verifiable on the ground and thus a bit against > the OSM-spirit! Their disappearing nature thus is a bonus. > > Practically speaking, our routeplanner should be able to figure out a > decent route over missing links. > I think in general, until most of them are signposted, they all (or most of them) are hard to verify on the ground. > *The website fietssnelwegen.be <http://fietssnelwegen.be>* > > First of all, the earlier link lacked one S. For the record, the correct, > working website is https://fietssnelwegen.be/ > > I've always considered that website as being informative for the public - > and as how they were planned years ago with quite a bit of guesswork. It > looks to me that they took a map and drew some approximate lines on them, > open to change. > > In the Veltem case could be an example of that where the plans were > amended. This view also answers the question on what to map: in my opinion, > the signposted cycle network *is* the official network, even if this > website happens says otherwise. Even more, it simply indicates that > fietssnelwegen.be should be updated, not that OSM should copy incorrect > data. > I had access to the official data, and I agree that fietssnelwegen is only indicative, but as far as I understood, the official itinerary will pass through the center of Veltem. So I have no idea why it is now signposted south of the railroad in the field. I expect that this will change at some point. > About your alternative for F203 passing Kraainem via Molenstraat instead: > maybe, because the signs aren't placed yet, we should try contact the > official instances and try to change the F203 there? It clearly isn't to > late for that and would make for a better, safer route. It seems to have > happened that way in the Veltem case as well. > Yes, I hope they will come to their senses with that one. Lobbying is on its way, but it won't hurt if we all write them a little email... > At last: why aren't they just using an overpass-based map? It could show > the status, surface, lit=yes/no for each segment and calculate all of that > live! > No idea, but I don't think they actually make use of OSM data. > *The master relation* > > At last, I've also created a master relation containing all the F*: > https://www.openstreetmap.org/relation/6682883 > > All current cycle highways are included in that, but as I'm not familiar > how master relations work, the tagging could probably be improved. Feel > free to edit and/or let me know how this could be improved. > > With kind regards and looking forward to more input, > Pieter > Great! Jo >
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
