Re: [OSM-talk] Survey about OSM communication behaviors

[Greg Troxel]

Marc_marc  writes:

> Hello,
>
> Le 28.04.23 à 15:29, Marjan Van de Kauter a écrit :
>> We are doing a research project on how OpenStreetMap  users interact
>> with each other.
>
> I am impressed (and disappointed) that those who do these surveys
> have still not learned that part of the active opendata community
> does not wish to ally a closeddata based enterprise (nominally:
> no use of google forms for some of us).
> I leave it to you to poll those who have a reduced sensitivity
> on the subject

Strongly seconded.  "Survey" implies confidentiality.  Please do not use
services that have an organizational conflict of interest that is not
possible to mitigate.  Please realize that this selection bias
invalidates your results.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Survey about OSM communication behaviors

[Allan Mustard]

In the 2021 community survey, which used Limesurvey as the platform, 
respondents came from 121 countries.[1] The countries with apparent 
access to Limesurvey included China (24 respondents out of those who 
included demographic data), Iran (16), Somalia (2), and South Sudan (2).


cheers,
apm

[1] 
https://wiki.osmfoundation.org/wiki/File:2021_OSMF_survey_country_respondents.ods



Date: Fri, 28 Apr 2023 23:16:05 +0100
From: Andy Townsend
To:talk@openstreetmap.org
Subject: Re: [OSM-talk] Survey about OSM communication behaviors
Message-ID:<647cf4a6-de0a-34ac-2d7a-980e65c0c...@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

On 28/04/2023 22:50, Allan Mustard wrote:

Rather than criticize the CWG for using Google because certain people
are restricted by their governments from using Google services, it
would be more useful to suggest alternatives that might work in those
countries.

Mikel already mentioned that OSMF had used Limesurvey earlier; that was
also what the DWG used when we last ran a survey a while back, and what
the organisers of this survey have suggested they will use it too (in
various of the other channels that it has been announced).? I don't have
up to date info on where that might be blocked, but at least a couple of
the channels in which this survey has been announced have contributors
who may have more up to date info on whether something is reachable or
not - from both of the countries you mentioned.**

Best Regards,

Andy

** I'm not being more specific because I don't want to advertise an
activity that might be "frowned upon" in a particular country, or which
particular OSM channel people doing that might be found in.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed automated edit of some barrier=kerb kerb=raised nodes (forum crosspost)

[osmuser63783 via talk]

Thanks.

> can you share the ids of the objects in your query that meet your dual
> criteria of "kerb=raised added by SC, barrier=kerb added by iD?"

There are 1,059 nodes that meet these criteria (or met them when I last ran the 
script to identify them). You can find 100 examples here:
https://community.openstreetmap.org/t/proposed-edit-of-some-barrier-kerb-kerb-raised-nodes/98038/13

Discourse won't let me add the full list to the forum post but I'll email it to 
you.

I have checked a lot of them. I am fairly sure that all of them are indeed 
mistakes. For example, the example you give 
(https://www.openstreetmap.org/node/9407931159) is not on that list because it 
does not conform to the pattern described (SC adds kerb=raised, iD adds 
barrier=kerb).

> - a complete error (often a wrong position) -> removing barrier=kerb tag is 
> ok but keeping kerb=* mean that someone will have to go over these objects 
> again

> https://www.openstreetmap.org/node/2405171
> this is a good example of the problem I am talking about
> you removed barrier=kerb and that is a correct removal
> but the main tag is still missing: if people cross the road at this point 
> (given the connecting paths on both sides of the road), it's clearly 
> highway=crossing
> if it is deemed not to be a highway=crossing because there is another  one 
> nearby, then the paths crossing the road should be modified to use the 
> existing pedestrian crossing
https://www.openstreetmap.org/node/2665802262
> so in the end, the node is still erroneous: what does kerb=raised refer to 
> here? it's still not maped, so every data user would have to play the  
> guessing game between "there is a missing barrier=kerb" affecting vehicles" 
> and "there is a missing highway=crossing" and "error there is nothing"

What I am proposing is essentially to revert these nodes to their previous 
state: after someone added kerb=raised using StreetComplete, but before someone 
else added barrier=kerb. So yes, these 1,059 nodes will be left with 
kerb=raised. But there are already about 5,000 nodes with kerb=raised on roads 
(https://overpass-turbo.eu/s/1unD), most of them added by StreetComplete. More 
such nodes are being created all the time.

For all of these nodes, the data consumer has to play the guessing game you 
describe. Therefore I agree with you that kerb=raised is ambiguous and not the 
best solution to say that there is a kerb on each side of a road at this point. 
In my view, something like sidewalk:both:kerb=raised would be better. Others 
have used kerb:location=footway. Others suggest crossing=informal (because 
there are objections to tagging points as crossing=unmarked where there is no 
crossing infrastructure). There are countless possible solutions, and there is 
an ongoing discussion with the developer of StreetComplete here: 
https://community.openstreetmap.org/t/tagging-kerbs-on-crossings/9290/24

Please contribute your thoughts to that discussion. Once there is a consensus, 
we can think about a separate mechanical re-tagging of the nodes that have been 
tagged kerb=raised by StreetComplete.

> if we aim for quality, there is no urgency

That is true, there is no rush, and of course I won't proceed as long as there 
are concerns.

The reason I am motivated to fix these nodes soon is because they lead to 
routing issues in routers that (correctly, in my view) avoid routing vehicles 
over barrier=kerb. See the examples at 
https://community.openstreetmap.org/t/barrier-kerb-kann-zu-routing-problemen-fuhren-osrm/97348.
 The discussions on this topic have been going on since February  
(https://community.openstreetmap.org/t/tagging-kerbs-on-crossings/9290).

Therefore I think that we can safely remove barrier=kerb from the 1,059 nodes 
now and that will solve the immediate routing issues for routers that trust 
that barrier=kerb means that there is a kerb across the road. Once we have 
decided what to do with the 5,000 or so + 1,059 nodes with kerb=raised - this 
probably requires a longer discussion - we can then discuss separately what to 
replace that tag with.

What do you think?

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed automated edit of some barrier=kerb kerb=raised nodes (forum crosspost)

[Marc_marc]

Le 28.04.23 à 18:50, osmuser63783 via talk a écrit :
Example changeset: https://www.openstreetmap.org/changeset/135319439 



https://www.openstreetmap.org/node/2405171
this is a good example of the problem I am talking about
you removed barrier=kerb and that is a correct removal
but the main tag is still missing: if people cross the road at this 
point (given the connecting paths on both sides of the road), it's 
clearly highway=crossing
if it is deemed not to be a highway=crossing because there is another 
one nearby, then the paths crossing the road should be modified to use 
the existing pedestrian crossing 
https://www.openstreetmap.org/node/2665802262
so in the end, the node is still erroneous: what does kerb=raised refer 
to here? it's still not maped, so every data user would have to play the 
guessing game between "there is a missing barrier=kerb" affecting 
vehicles" and "there is a missing highway=crossing" and "error there is 
nothing"




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed automated edit of some barrier=kerb kerb=raised nodes (forum crosspost)

[Marc_marc]

Le 21.04.23 à 19:53, osmuser63783 via talk a écrit :

I am 100% sure that the barrier=kerb is wrong.


can you share the ids of the objects in your query that meet your dual 
criteria of "kerb=raised added by SC, barrier=kerb added by iD?"


I have reviewed 100 objects with satellite view in 3 countries:
I find 4 cases (without checking the editor)
- cases where it is indeed the kerb 
https://www.openstreetmap.org/node/9407931159
- a complete error (often a wrong position) -> removing barrier=kerb tag 
if ok but keeping kerb=* mean that someone will have to go over these 
objects again
- a pedestrian crossing with highway=crossing -> removing barrier=kerb 
only if it is kerb=raised -> someone will have to go

over the other kerb=* with the same logic
- a pedestrian crossing without highway=crossing -> your EA removes 
barrier=kerb only if it is kerb=raised -> you will have to go over
the other kerb=* with the same logic, your EA does not add the missing 
highway=crossing tag -> someone will have to go over these objects again


if I make stats: 1314 objects barrier=kerb kerb=raised on road
14 are highway=crossing and may be correct after your AE (but there
will remain 1148 barrier=kerb + higway=crossing object to treat)
1300 objects will not have a main tag and will have to be modified
a second time
some of them will have to be modified to add barrier=kerb again

maybe the additional criteria "kerb=raised added by SC,
barrier=kerb added by iD?" improve that


I would like to run it this weekend.


if we aim for quality, there is no urgency



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] [import] import partiel des adresses en France

[Christian Quest]

Le 26/04/2023 à 09:36, Zimmy ZIMMERMANN a écrit :

Toute initiative permettant de verser de la donnée manquante dans OSM
mainte fois vérifiée par différents acteurs est non seulement nécessaire
mais urgente car nous restons en mode amateur avec une position ‘verifié
sur le terrain’.

Jean-Louis



Sauf que cette donnée adresse, même certifiée, n'a bien souvent pas été 
vérifiée maintes fois sur le terrain, peut être même pas une fois 
d'ailleurs sauf peut être sur la CCPRO ;)


La qualité de la BAN n'a pas tant évolué depuis qu'on a démarré BANO en 
2014.


Elle est plus exhaustive, c'est sûr, mais pour les noms de voies et la 
position des adresses ce n'est pas au niveau pour un import automatisé.


Pifometre est très adapté pour une intégration propre, qui prendra du 
temps, c'est sûr.



On le savait déjà en 2014 quand on a décidé de démarrer BANO plutôt que 
d'importer les adresses que l'on pouvait extraire du cadastre. Le 
contexte n'a pas tant changé que ça, donc le consensus de l'époque me 
semble encore valable.


Je suis donc moi aussi opposé encore actuellement à un import (vu que 
les échanges ici semblent pris pour une forme de vote).


--
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr