Re: [Tagging] What does bicycle=no on a node means?
Am 07.10.2020 um 23:01 schrieb Emvee via Tagging: Basic question I think, for a bicycle router bicycle=no on a node means it should "avoid" crossing the node likely by adding a moderate penalty as the cyclist could make the choice to dismount passing the node. I know at least on bicycle router implementing it this way, see https://github.com/abrensch/brouter/issues/265 Really just by bicycle=no on a node? It does not check for barrier=* first? I think that would be a bad idea. Question now is if this rule should be applied differently if it is used in combination with highway=crossing. At least I think so. The recent "meaning of highway=crossing + bicycle=no" thread makes the case that it means "you cannot use this crossing to cross road while cycling, it does not affect legality of cycling on the road" I think so. The main tag ist highway=crossing. I see this as common practice (for whom this crossing is meant). I think this is a bad idea as that way the access can not be evaluated in node context (a router would have to look at the incoming and outgoing way) while adding bicycle=yes/no to a crossing node does not give "additional possibilities"; You can check the simple node context - as a bicycle=no (should) never stand alone on a node. by giving the right access rights on the ways connecting to the node all possible access scenarios can be covered. That can be a solution for crossings. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] What does bicycle=no on a node means?
Basic question I think, for a bicycle router bicycle=no on a node means it should "avoid" crossing the node likely by adding a moderate penalty as the cyclist could make the choice to dismount passing the node. I know at least on bicycle router implementing it this way, see https://github.com/abrensch/brouter/issues/265 Question now is if this rule should be applied differently if it is used in combination with highway=crossing. The recent "meaning of highway=crossing + bicycle=no" thread makes the case that it means "you cannot use this crossing to cross road while cycling, it does not affect legality of cycling on the road" I think this is a bad idea as that way the access can not be evaluated in node context (a router would have to look at the incoming and outgoing way) while adding bicycle=yes/no to a crossing node does not give "additional possibilities"; by giving the right access rights on the ways connecting to the node all possible access scenarios can be covered. Started this new thread as I just subscribed to the tagging list and I think this title is more focusing on what is the point but please have a look at "meaning of highway=crossing + bicycle=no" thread for the other side of the story, https://lists.openstreetmap.org/pipermail/tagging/2020-October/055611.html Would be good to get some feedback from others as this has been a (too) long debate between only me and the of the author of the "meaning of highway=crossing + bicycle=no" thread, see https://wiki.openstreetmap.org/wiki/Talk:Tag:highway%3Dcrossing#highway.3Dcrossing_with_bicycle.3Dno ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Face and license blurring (GDPR territories)
I didn't see anything about them reverting that decision. They still remove original images. Unless you've got a source on the they changed it again On Wed, Oct 7, 2020, 11:49 Niels Elgaard Larsen wrote: > Simon Poole: > > > > Am 07.10.2020 um 01:13 schrieb Niels Elgaard Larsen: > >> ... > >> You will probably have to let users add and remove blurs. > >> That is what Mapillary do. > >> > > They do not, they stopped providing that facility literally years ago, > and they've > > gone as far as no longer storing unblurred images even for a limited > time now. > > They stopped it for a while. Then they put it back in. Now (checked > today) under > edit there is a "edit privacy blurs" > there is still a "Download unprocessed originals" option. > > Maybe they had too many positives. > > Then testing AI solutions, make sure to test it on images with a lot of > street signs. > > > > > > -- > Niels Elgaard Larsen > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] railway=station areas
Am Mi., 7. Okt. 2020 um 10:31 Uhr schrieb Andrew Harvey < andrew.harv...@gmail.com>: > In practice many are mapped as the same area, but that's usually only > because unless you're a train operator it can be hard to actually survey > where the station starts and ends from the train network point of view. > Some people have suggested this would be the area between the first and last switch (and all dead end rails inside these switches), other definitions that have been proposed are referring to the signals. I am not sure there is a significant difference between the two, but it seems this is something you can roughly estimate also without professional background information. It is maybe worth pointing out that railway=station according to the wiki can be also used for stations without passenger access (goods station). Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Face and license blurring (GDPR territories)
Am 07.10.2020 um 11:46 schrieb Niels Elgaard Larsen: ... They stopped it for a while. Then they put it back in. Now (checked today) under edit there is a "edit privacy blurs" there is still a "Download unprocessed originals" option. The "Download unprocessed originals" returns blurred images for me even for very recent (that is uploaded last Friday) uploads, so I would suspect that this is simply a case of the UI not being adapted to their new business rules (it may be possible to still add further blurs, but removing them wouldn't seem to be possible). OpenPGP_0x4721711092E282EA.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Face and license blurring (GDPR territories)
Simon Poole: Am 07.10.2020 um 01:13 schrieb Niels Elgaard Larsen: ... You will probably have to let users add and remove blurs. That is what Mapillary do. They do not, they stopped providing that facility literally years ago, and they've gone as far as no longer storing unblurred images even for a limited time now. They stopped it for a while. Then they put it back in. Now (checked today) under edit there is a "edit privacy blurs" there is still a "Download unprocessed originals" option. Maybe they had too many positives. Then testing AI solutions, make sure to test it on images with a lot of street signs. -- Niels Elgaard Larsen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] railway=station areas
On Wed, 7 Oct 2020 at 18:42, Martin Koppenhoefer wrote: > I know we have already been discussing this several times in the past, but > due to recent editing disagreements in the wiki, I am raising it again. > > For several years, we had railway=station on a way documented in the wiki > as the complete area of a train station. > https://wiki.openstreetmap.org/wiki/File:A-simple-station.svg > > This was also discussed in the wiki: > https://wiki.openstreetmap.org/wiki/Talk:Tag:railway%3Dstation#Station_an_area_.3F > > And it is what we do around here locally. It is also what the definition > of railway=stations says, the tag defines "A railway station". > > A fellow editor now insists that this tag should be used on the same area > as defined for public_transport=station, i.e. the part of the train station > that is accessible by passengers (platforms and buildings near the > platforms). > https://wiki.openstreetmap.org/wiki/File:Railway%3DStation.svg > > I am reaching out to the wider community because the user and me could not > come to an agreement. > > https://wiki.openstreetmap.org/w/index.php?title=Tag:railway%3Dstation&action=history > I agree that for a long time the distinction between railway=station areas and public_transport=station areas are as you've noted and as the wiki used to say. I think it makes sense to retain this convention so that the railway is from the rail network/infrastructure point of view and public transit from the passenger point of view. In practice many are mapped as the same area, but that's usually only because unless you're a train operator it can be hard to actually survey where the station starts and ends from the train network point of view. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] railway=station areas
I know we have already been discussing this several times in the past, but due to recent editing disagreements in the wiki, I am raising it again. For several years, we had railway=station on a way documented in the wiki as the complete area of a train station. https://wiki.openstreetmap.org/wiki/File:A-simple-station.svg This was also discussed in the wiki: https://wiki.openstreetmap.org/wiki/Talk:Tag:railway%3Dstation#Station_an_area_.3F And it is what we do around here locally. It is also what the definition of railway=stations says, the tag defines "A railway station". A fellow editor now insists that this tag should be used on the same area as defined for public_transport=station, i.e. the part of the train station that is accessible by passengers (platforms and buildings near the platforms). https://wiki.openstreetmap.org/wiki/File:Railway%3DStation.svg I am reaching out to the wider community because the user and me could not come to an agreement. https://wiki.openstreetmap.org/w/index.php?title=Tag:railway%3Dstation&action=history Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
