Re: [OSM-talk] Help with reverting a changeset (somebody deleted weeks and weeks of work)

[Pierre Béland via talk]

I reverted the nodes and ways. I think that the relations should be edited 
carefully by someone who knows the content. 
See https://www.openstreetmap.org/changeset/134706111

Pierre


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

Re: [OSM-talk] Duplicate Buildings

[Pierre Béland via talk]

My workflow in the last few days was to select/process series of way id's from 
Frederik list with closed iterations that look to come from the same changeset. 

Using the JOSM Overpass query function with instructions I provided earlier, it 
is easy to download such a block of data, validate and correct with the help of 
the validation functionality. 

But when there is both quadri-duplicates combined with Bad quality problem 
illustrated from the overpass query below, I leave it to Quality teams involved 
in the project (here #hotosm-project-11827) to document and correct. 

See http://overpass-turbo.eu/s/1sQQ

Pierre



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

Re: [OSM-talk] Duplicate Buildings

[Pierre Béland via talk]

From the OSM-id list of Frederik, it is possible to query with Overpass. For 
the following list:

id1,id2,id3,id4
-15538065,-15538064,-15538063,1137657546

I isolate negative values and query as relation, others as way.

[out:xml][date:'2023-03-05T00:00:00Z'];
(
  way(id: 1137657546  
 );
  relation(id: 
15538065, 15538064, 15538063
 );
);
out meta;
>; out meta;

Pierre

Envoyé avec la messagerie sécurisée Proton Mail.

--- Original Message ---
Le mercredi 15 mars 2023 à 07:11, Marc_marc  a écrit :

 
> 
> in fact I was thinking about the overpass turbo query :)
> to test it in my area
> 
> > the 4 dates of edit.
> 
> 

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

Re: [OSM-talk] Duplicate Buildings

[Pierre Béland via talk]

Hi Marc,

I created a csv file available on wetranser for 7 days. It contains 
901 quadruplets. For each line, the 4 OSM id's (similar to Frederik list)  + 
the 4 dates of edit.

See https://we.tl/t-rt9KSsZXBD

The osm-id list below refers to 77 buildings (ways) with level, layer or 
building:part attributes:

310361827, 310362676, 310362677, 310362678, 618340953, 618340954, 618340955, 
618340956, 618489859, 618489861, 618489863, 618489865, 618763855, 618763856, 
618763857, 618763858, 626660536, 626660537, 626660538, 626660539, 626660540, 
626660541, 921548773, 921548775, 921550589, 921550590, 921550591, 921550592, 
921550593, 921550594, 921550595, 921550596, 921550597, 921550598, 951883751, 
951883903, 951884118, 951884269, 951884402, 951884775, 951885143, 951885226, 
951885296, 951885425, 951885509, 951885788, 969467331, 1011631197, 1011631208, 
1011631209, 1078444684, 1078444685, 1078444686, 1078444687, 1078444688, 
1078444706, 1078444707, 1078444708, 1078444709, 1078444710, 1078444711, 
1078444712, 1078444713, 1078444714, 1078444715, 1078941994, 1078941995, 
1078941996, 1078941997, 1078941999, 1078942000, 1078942001, 1078942002, 
1078942003, 1078942004, 1078942005, 1078942006


Pierre


--- Original Message ---
Le mardi 14 mars 2023 à 11:51, Marc_marc  a écrit :


> Le 14.03.23 à 13:45, Pierre Béland via talk a écrit :
> 
> > I imported the osm metadata using overpass
> 
> 
> can youu share it to avoid having to make it again :)
> 


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

Re: [OSM-talk] Duplicate Buildings

[Pierre Béland via talk]

Marc, I will revise and share data. 

First, below are the instructions to extract relations metadata with 

[out:csv(::changeset, ::timestamp,::user, ::type, ::id, building, highway, 
level, layer, 'building:part', 'building:roof')];
relation(id: 
3240506, 3240507, 3240508, 3240509, 3240510, 3240511, 3240512, 3240513, 
3240514, 3240515, 3240516, 3240517, 8325855, 8325856, 8325857, 8325858, 
8853592, 8898812, 8898813, 8898814, 9168214, 9168215, 9168216, 9168217, 
9168218, 9168219, 9173897, 9173898, 9173899, 9173900, 9173901, 9173902, 
9173903, 9173904, 9173905, 9175052, 9175053, 9175054, 9175055, 9796369, 
9796370, 9796371, 9796372, 10326411, 10326412, 10326413, 10326414, 10784846, 
10784847, 10784848, 10784849, 11305092, 11305093, 11305094, 11305095, 13965409, 
13965410, 13965411, 13965412, 14627860, 14627861, 14627862, 14627863, 15538063, 
15538064, 15538065 
   ); out meta;
Overpass. We can spot other relations with the level attribute.


Pierre

--- Original Message ---
Le mardi 14 mars 2023 à 11:51, Marc_marc  a écrit :


> Le 14.03.23 à 13:45, Pierre Béland via talk a écrit :
> 
> > I imported the osm metadata using overpass
> 
> 
> can youu share it to avoid having to make it again :)
> 
> > Simple Building duplicates from the same contributor are the easy ones to 
> > correct.
> 
> 
> yes, on the condition that you can easily detect when the contributor
> wanted to represent a simple building ?
> I imagine that a first criterion could be the absence of the level layer
> tag (which we see badly used in one of your examples) and perhaps
> building:level
> 
> > osm type nb of quaddup objects
> > way 1 838 3352
> 
> 
> maybe best to focus on that first
> 
> > See https://www.openstreetmap.org/relation/13965412 that contains 
> > way/677238859 with inner role to 6 relations that represent each level of 
> > the building.
> 
> 
> commented https://www.openstreetmap.org/changeset/118924402
> 
> > one building is represented with one way (6 nodes) and 3 relations in which 
> > this way has role=outer.
> > way 1137657546 building=cabin
> > Relation : 15538065 building=yes
> > Relation : 15538064 building=yes
> > Relation : Horsnæs Fangststation (15538063) place=locality
> 
> 
> ccommented https://www.openstreetmap.org/changeset/133075628
> 
> > These are four different relations.
> > -10326414 -10326413 -10326412 -10326411
> > They all share these 2 buildings as outer members.
> > 48002128 505561207
> 
> 
> what's strange is to have managed to do this with iD
> but that's three mistakes :
> - duplicate
> - the garage is not a house
> - the address in Switzerland represents an entrance door and by
> extention the building if this one has only one address. if the no. 7
> represents the house, the garage does have the no. 7 (but probably the
> number 7.1 which is rarely tagged in osm)
> 
> Regards,
> Marc
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] Duplicate Buildings

[Pierre Béland via talk]

Using id's from the Frederick quadruplicate list, I imported the osm metadata 
using overpass. Note thate the negative values in the list represent relations.

The table below shows that the majority of quadruplicate cases implicate only 
one contributor. Simple Building duplicates from the same contributor are the 
easy ones to correct.  It is different for the relations or combination of 
relations/ways where it is sometime necessary to revise the tagging as a 
contributor misused duplicates to represent various levels of a building.

osm typenb ofquaddupobjects
contributors  cases
relation168   272
relation2 936
way 1   838  3352
way 2   134   536
way 3 520

See https://www.openstreetmap.org/relation/13965412 that contains way/677238859 
with inner role to 6 relations that represent each level of the building.

There are also strange schemas. For this block, one building is represented 
with one way (6 nodes) and 3 relations in which this way has role=outer.
  way 1137657546building=cabin
  Relation : 15538065   building=yes
Relation : 15538064 building=yes
Relation : Horsnæs Fangststation (15538063) place=locality

These are four different relations.
-10326414   -10326413   -10326412   -10326411
They all share these  2 buildings  as outer members.
48002128505561207


Pierre


--- Original Message ---
Le samedi 11 mars 2023 à 07:35, Frederik Ramm  a écrit :


> Hi,
> 
> I think an automatic fix of the problem is possible, however it would be
> a good idea to try and find out what the root cause of the problem is -
> bad software, bad imports, bad instructions?
> 
> To get an idea of how big the issue is, I did this on a standard
> rendering database:
> 
> create table buildings as (select way,osm_id from planet_osm_polygon
> where building is not null)
> 
> select a.osm_id, b.osm_id into duplicates from buildings a, buildings b
> where a.osm_id < b.osm_id and a.way ~= b.way and st_equals(a.way,b.way);
> 
> This took a few days - probably it could have been done more efficiently
> - and resulted in a list of about 70k buldings world-wide that are exact
> duplicates (geoetry-wise) of other buildings. The list is here:
> 
> http://www.remote.org/frederik/tmp/duplicatebuildings.csv
> 
> Some buildings are in OSM three or four times (contained i nthe above in
> the form of "a is duplicate of b, b is duplicate of c") but I've
> extracted them in extra files:
> http://www.remote.org/frederik/tmp/triplcatebuildings.csv and
> http://www.remote.org/frederik/tmp/quadruplicatebuildings.csv)
> 
> I don't have the time to analyse the situation in more detail at present
> so if anyone wants to take the above lists as a basis for deeper analysis...
> 
> Cheers
> Frederik


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

Re: [OSM-talk] Should we be mapping transformers and powerlines?

[Pierre Béland via talk]

Why are we mapping these infrastructures. Well these are major infrastructures 
and quite an asset in OSM to let compare from country to country. Dont you know 
https://openinframap.org/ ?

I do map major infrastructures such as dams, hydro-electric power plants and 
substation and high voltage power lines. I dont think that we should neglect 
these infrastructures. Like for highway networks, we should have a 
classification of major high voltage power lines and render them to lower zooms 
then 14. Power Plants and Substations should be searchable in Nominatim. To 
hide these wont protect them as they can be observed easily from the ground.

Pierre​

--- Original Message ---
Le mercredi 18 janvier 2023 à 22:35, Clifford Snow  a 
écrit :

> On Wed, Jan 18, 2023 at 7:05 PM john whelan  wrote:
>
>> Apparently you can do a lot of expensive damage by firing a rifle bullet 
>> through them as happened more than once in the US and given the situation in 
>> Europe at the moment is there a risk that something similar could happen 
>> there?
>>
>> Should we have a process that says some things should not be mapped?
>>
>> I seem to recall that the location of the pipeline that supplies aviation 
>> fuel to airports is considered an official secret in the UK.
>>
>> Thoughts?
>
> I live in one of the states where people fired at and damaged a power 
> substation so I'm concerned about the safety of our infrastructure. 
> Unfortunately there are many infrastructures that are vulnerable to attacks. 
> Such facilities as water plants, dams, bridges, transportation, pipelines, 
> hospitals, and a host of others. But I believe that mapping them can also 
> help. If you go back to the idea that "security through obscurity" I think 
> you'll find that it is just an illusion.
>
> BTW - those caught and charged with damaging a power substation here were 
> looking to rob some stores. We all assumed it was right wing radicals.
>
> Best,
> Clifford
>
> --
>
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Updating of land/water polygons (based on natural=coastline) is too slow and unreliable

[Pierre Béland via talk]

The Saguenay River, a tributary of the Saint-Lawrence Estuary and a major river 
with salty water and tidal is an example where some contributors might have 
difficulty to understand that such rivers correspond to the definition of "sea" 
and should be tagged with natural=coastline. This Fjord more then 100 km long 
is the  southernmost on the planet and connects to a large Estuary. The 
Saint-Lawrence is 25 km wide at the junction of the Saguenay. This thread made 
be go back and notice that a contributor silently removed the coastline a year 
ago.
https://www.openstreetmap.org/changeset/71656040

The monitoring problem is not only technical with broken multipolygons and 
floating continents but also when people decide to remove parts already defined 
as coastlines not understanding this definition and without consensus with the 
community.
 
Pierre 
 

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

Re: [OSM-talk] mspray stealth organized mapping

[Pierre Béland via talk]

 Le vendredi 22 mai 2020 10 h 40 min 51 s UTC−4, Mateusz Konieczny via talk 
 a écrit :  
 
> Are you sure that in 72427535 buildings were just moved?
If I place the mouse over a red oultine (old building), Achavi reports «Modify 
geometry»
Loading the changeset in an editor for validation, I confirm that I only see 
create and modify actions.
https://www.openstreetmap.org/api/0.6/changeset/85329885/download
 > buildings and college that used to be mapped at
> https://www.openstreetmap.org/#map=18/-12.94547/28.64318
> It is gone thanks to https://overpass-api.de/achavi/?changeset=72427535
Achavi reports for old building «delete way» and «delete node»
Pierre 

 

Le vendredi 22 mai 2020 10 h 40 min 51 s UTC−4, Mateusz Konieczny via talk 
 a écrit :  
 
 Are you sure that in 72427535 buildings were just moved?
buildings and college that used to be mapped at
OpenStreetMap


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
OpenStreetMap

OpenStreetMap is a map of the world, created by people like you and free to use 
under an open license.
 |

 |

 |




It is gone thanks to https://overpass-api.de/achavi/?changeset=72427535

BTW how one may undelete delete buildings? Straight revert will delete new ones,
what may be not needed.

Use reverter plugin in JOSM, copy buildings to a new layer, delete reverter 
layer, save?

Is there some script that I can run with "revert deletions only in changeset 
XYZ"?

May 22, 2020, 15:47 by talk@openstreetmap.org:

Le vendredi 22 mai 2020 07 h 29 min 19 s UTC−4, Frederik Ramm 
 a écrit :
> Sometimes users deleted a large number of
> buildings e.g. here https://overpass-api.de/achavi/?changeset=72427535
> without giving a clear reason

Looking at Achavi, red outlines make us think objects were deleted. But in 
fact, the buildings were simply slightly moved to realign to DigitalGlobe 
imagery (not Bing).  And no correction of geometry was made, even where too 
many and unsquared angles to represent a rectangular building. Also Tags are 
systematically added:  
    "mapper"="mspray4"
    "source"="Akros"
 



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

Re: [OSM-talk] mspray stealth organized mapping

[Pierre Béland via talk]

 Le vendredi 22 mai 2020 07 h 29 min 19 s UTC−4, Frederik Ramm 
 a écrit :  > Sometimes users deleted a large number of
> buildings e.g. here https://overpass-api.de/achavi/?changeset=72427535
> without giving a clear reason
Looking at Achavi, red outlines make us think objects were deleted. But in 
fact, the buildings were simply slightly moved to realign to DigitalGlobe 
imagery (not Bing).  And no correction of geometry was made, even where too 
many and unsquared angles to represent a rectangular building. Also Tags are 
systematically added:  
    "mapper"="mspray4"
    "source"="Akros"

 
Pierre 
 

  

 Hi,

the "mspray" accounts were blocked in July 2019 for problematic edits
and failing to document properly. The project leader has contacted DWG
on 15 May 2020 asking what needs to be done to unblock the accounts, and
was informed by us that:

> the "mspray" users have only been blocked until they read the block
> message; the accounts can be used again now. But they will be blocked
> again, and their edits potentially reverted, if they continue to
> disregard OSM rules.
> 
> To re-iterate, the issues were:
> 
> * accidentally "squaring" water areas
> * no proper changeset comments
> * no documentation of the project
> 
> As a general rule, someone encountering an edit by an "mspray" user
> should be able to see (through a link from the user profile for example)
> what kind of project this is, who is running it, and what the goals of
> the project are. Ideally, such project should be discussed with the
> community before they commence. And changeset comments should explain
> the concrete action, for example "tracing buildings in XY region". Also
> the frequent mention of "evwhsdigitalglobe" is puzzling; this is not a
> well-known source in OSM. Sometimes users deleted a large number of
> buildings e.g. here https://overpass-api.de/achavi/?changeset=72427535
> without giving a clear reason (the changeset comment "reveal enumeration
> # malaria elimination" is not enough to explain why you deleted dozens
> of buildings).

If you feel they are disregarding that message, we are happy to block
them again.

Bye
Frederik


-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] Bridge area construction

[Pierre Béland via talk]

On 5. May 2020,   Martin Koppenhoefer wrote:


I think the common tag would be landuse=construction



I dont think that it is appropriate to superpose a landuse over a waterway.

Since the tag man_made=bridge is used, it seems better to  refer to the 
construction project with the tags as proposed by Jack Armstrong

- man_made=construction- construction=bridge- layer=1

 
Pierre 
 

Le mardi 5 mai 2020 17 h 53 min 59 s UTC−4, Martin Koppenhoefer 
 a écrit :  
 
 

sent from a phone

On 5. May 2020, at 22:27, Jack Armstrong  wrote:



I assume the best way to map a large bridge area that's under construction 
would be with the minimum following tags? I'm not asking about the ways 
associated with/on the bridge.
man_made=constructionconstruction=bridgelayer=1


I think the common tag would be landuse=construction
Cheers Martin ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] healthsites.io breaks OSM data, do not use

[Pierre Béland via talk]

Thanks to the Healthsites.io Team.  

See my comments below about the keys added.

First point is about the addr:full  The addr wiki page suggests to avoid this 
key if possible. See https://wiki.openstreetmap.org/wiki/Key:addr
Second point,, the rule in OSM is to not abbreviate addresses.See  changeset 
82308472,  way=28712045addr:full=1825 E Warner Rd, Tempe, AZ 85284

The street name is different from the highway way 597611061 : East Warner Road. 
To my understanding, this might create problem with navigation tools. Third 
point : source = should be put on the changeset especially if you only added 
tags to an existant OSM object.  

Fourth point : One object per changeset adds burden to OSM contributors 
validating edits. This should be avoided as much as possible.
regard
Pierre 
 

Le dimanche 22 mars 2020 09 h 38 min 18 s UTC−4, sharehealthdata share 
 a écrit :  
 
 Dear OSM Moderators

Thank you for raising the issue with data loss caused by edits through 
Healthsites.io. Our project is an important focal point for people looking to 
create, edit, visualise and extract data health facility data from OSM - 
especially in this trying time with COVID-19. We have fixed the underlying 
issues and also corrected any data issues that arose because of this issue.  
Our team is on standby and will move to rapidly resolve any problems surfaced 
by the OSM community
.
A detailed list of data fixes we have done is available here:  
https://github.com/healthsites/healthsites/issues/1357#issuecomment-602165455 

Thank you everyone,
Keep Safe
Regards

The Healthsites.io Team
ᐧ
On Sun, Mar 22, 2020 at 1:05 PM  wrote:

Send talk mailing list submissions to
        talk@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.openstreetmap.org/listinfo/talk
or, via email, send a message with subject or body 'help' to
        talk-requ...@openstreetmap.org

You can reach the person managing the list at
        talk-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of talk digest..."


Today's Topics:

   1. Re: healthsites.io breaks OSM data, do not use (Mikel Maron)


--

Message: 1
Date: Sun, 22 Mar 2020 11:03:15 + (UTC)
From: Mikel Maron 
To: Frederik Ramm ,  Talk Openstreetmap
        ,  Oleksiy Muzalyev
        
Subject: Re: [OSM-talk] healthsites.io breaks OSM data, do not use
Message-ID: <1795611632.59384.1584874995...@mail.yahoo.com>
Content-Type: text/plain; charset=UTF-8

Update:

https://github.com/healthsites/healthsites/issues/1357#issuecomment-602164476

The editor is disabled for now. 
They're working on fixing bad edits.

-Mikel

* Mikel Maron * +14152835207 @mikel s:mikelmaron






On Sunday, March 22, 2020, 03:37:43 AM EDT, Oleksiy Muzalyev 
 wrote: 





On 3/21/20 17:39, Frederik Ramm wrote:
> Hi,
>
> the "healthsites.io" web app allows you to contribute data to OSM,
> however if you modify existing OSM objects, it throws away all tags it
> does not know of. Until this bug is fixed, please refrain from using
> healthsites.io!
>
> You can track progress here
> https://github.com/healthsites/healthsites/issues/1357#issuecomment-602068556
>
> Bye
> Frederik
>
It is one more lesson of this outbreak that the emergency response tools 
are to be prepared and tested well beforehand.

By the way, a viral respiratory infection can be stopped, or at least 
slowed down, by mere physical separation of hosts, i.e. people, because 
it stops the exponential chain reaction.

That is why mapping with the reliable editor say an archeological site 
in a forest could be also very beneficial. As some people could hike to 
it on weekend, instead of going to an overcrowded city park.

And we shall also remember of ambulances. Sometimes it is very hard for 
a driver to find a location of an address. In some cases it may take 
hours. So the general overall improvement of the map should continue.

Best regards,

Oleksiy



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



--

Subject: Digest Footer

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


--

End of talk Digest, Vol 187, Issue 56
*

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

[OSM-talk] Covid19 OSM Community Buzz Challenge 1. Building overlaps

[Pierre Béland via talk]

For many, we are doing social distanciation staying at home. This is a great 
time to do some social proximity actions from internet. 

We can easily do some Quality actions easy enough to show to childs or 
relatives nervous to do something positive. Various tools can be used. The 
easiest one I propose is Osmose. For more aventurous, there is an Overpass 
query.
- http://osmose.openstreetmap.fr select building theme- 
https://overpass-turbo.eu/s/M4m Overpass query - you simply select the zone to 
cover

Pierre Béland on Twitter

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Pierre Béland on Twitter

“my #buzzOSM today: #OpenStreetMap community Quality challenge 1. Osmose 
theme:building or other Quality tools ...
 |

 |

 |




takes care, have fun :)
 
Pierre 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] fixme=name

[Pierre Béland via talk]

 Mar.12 2020 12 h 16 UTC−4, Volker Schmidt wrote :  
> It may have been a user who wanted to draw attention to the fact that she has 
> inserted a place>  without knowing the name.
 For the Mali example given by John, an Overpass query reports some 1,200 such 
points north of Mali, the majority added in 2013. Note that I did coordinate 
the humanitarian response at the time with Andrew Buck. See his message at the 
time https://lists.openstreetmap.org/pipermail/hot/2013-February/002802.html 

These names were added for the Mali humanitarian response in 2013 at the 
request of UN agencies and NGO's answering in the area.  If we remember, we did 
innovate at the time using Imagery tiles to spot villages in often flooded 
areas, then traced roads from these villages. Then NGIS data was imported. 
Since geolocation is often very imprecise, we did manually add these infos 
placing them at the best of our knowledge.
The local ressources are still quite limited in Mali even at the government 
level.  The OSM volunteer community has organized a few missions in the south 
to revise names but it is more difficult to deal with the northern area.  And 
badly, the volunteers do not manage the subsidies that were received from such 
humanitarian actions.


Pierre 

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

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Pierre Béland via talk]

Mar. 12 2020 10 h 43 min  UTC−4, Simon Poole wrote :
> To use a completely different example: assume that you purchase a TV set 
> paid by monthly instalments and you default on them. In civilised 
> countries that doesn't give the seller the right to break in to your 
> apartment and repossess the TV, they don't get to cut off electricity to 
> the flat and they don't get the right to stick big notices on your doors. 
> The seller needs to utilize the  whatever tools are provided by the legal 
> system, totally regardless off how upset they are and how righteous they 
> might feel about their actions. Simon
An other example 
Let say we produce bricks standing outside of the shop.  Since too many are 
stolen, we use a trick to make the bricks flashing with a message when they get 
in inappropriate hands. Can somebody sue us because their house is flashing 
with message about where the bricks come from ?

 
Pierre 
 

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

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Pierre Béland via talk]

 
Pierre 
 

   Mar.8, 2020 1byMateusz Konieczny 

> To be more clear: I fully support action like OSM France to actually enforce
> license requirements using methods like described here or by a legal action 
> like
> DMCA takedown notices against entities refusing to show a proper attribution.
  I also support such actions. To be less intrusive and more diplomatic, the 
box could be smaller and semi transparent, and the text rewrittten to be more 
specific What's about something like ? 

- WARNING : OSM Attribution is required for these tile products
- These OSM tiles are downloaded from openstreetmap-France tile server 
   without this website providing any visible attribution
- See https://www.openstreetmap.org/copyright
- Contact us at ti...@openstreetmap.fr

Mar 8, 2020, 20:26 by talk@openstreetmap.org:


Mar 8, 2020, 12:12 by si...@poole.ch:


I would be very very wary of doing anything that deliberately defaces a web 
site without consulting with a local (to the country the web site is in) 
lawyer, particularly if the message implies wrong doing.


Illegal use of OSM data and violating terms of use of service is a clear wrong 
doing.

I am not a lawyer, but showing message informing about violating license and 
terms of use of service seems 100% OK in case of website actually violating
OSM license.
And I fully support websites doing this.

To be more clear: I fully support action like OSM France to actually enforce
license requirements using methods like described here or by a legal action like
DMCA takedown notices against entities refusing to show a proper attribution.
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] #AttributionIsNotOptional experiment on OSM France tile servers

[Pierre Béland via talk]

You could use the navigator user language preference for the language to use 
for the message.

 
Pierre 
 

Le dimanche 8 mars 2020 11 h 40 min 47 s UTC−4, Christian Quest 
 a écrit :  
 
 Le 08/03/2020 à 16:00, Mario Frasca a écrit :
> well, it does look slightly invasive …


That's the goal... slightly invasive... and not time consuming for the 
tile server and myself.

Please, don't forget who's wrong here.


-- 
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk] MapRoulette - cryptic tasks

[Pierre Béland via talk]

Hi Martin, 

If we want to monitor revisions for a specific territory we take care of, I see 
that Maproulette Challenge offers a map where we can see I suppose individual 
objects/tasks for the area. Zooming in and out of the area, the numbers 
constantly change.  If I zoom-in, I cannot see the individual tasks neither see 
simply what is the object of the challenge for these tasks.

 
https://maproulette.org/browse/challenges?challengeSearch=-71.55601501464845%2C46.70691089512589%2C-70.99777221679689%2C46.908998382774506&location=intersectingMapBounds&sort=created%2C

Could MapRoulette API help to monitor an area by rapidly providing  a list of 
individual tasks + OSM object Id (ie. Challenge -OSM object id, problem / tag 
to correct, solution / tag proposed )  ?

Could you give example of API call for this ?
 


Pierre 
 

Feb.26 2020 10 h 05 min 52 s UTC−5, Martijn van Exel wrote :  
there is also an API call you can use. 

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

Re: [OSM-talk] Deletion of wiki page contributions Was Creation of "Data Items" by bot for undocumented tags

[Pierre Béland via talk]

Joseph,
If you were talking of fast food restaurants, I would understand that we expect 
to see these in hundred of countries.  But there are features that yes are not 
seen as intensively.

One fast food POI counts for one. One 500km route counts also for one.
This Overpass query shows that the tag is used in five provinces / territories 
in Canada, plus Norway and Sweden.
 
Please revert your undelete and if you are not happy with this, you should go 
to the Tagging list for discussion.

regard

Pierre 
 

Le mercredi 19 février 2020 09 h 38 min 44 s UTC−5, Joseph Eisenberg 
 a écrit :  
 
 The tag is documented at
https://wiki.openstreetmap.org/wiki/Tag:route%3Dsnowmobile - it has
been used 141 times only. I did not delete the documentation, but I
did remove the tag from
https://wiki.openstreetmap.org/wiki/Template:Map_Features:route, and
added a comment to
https://wiki.openstreetmap.org/wiki/Template_talk:Map_Features:route

This does not need to be on the main "Map features" page, which is a
curated list of the most commonly used tags, for new users, since it
is a new tag with few uses. This has nothing to do with my opinion of
the tag. It looks fine to me.

If you wish to add this tag to Map Features, there are 2 options:

1) Create a Proposal page and follow the process to get the tag
Approved (see https://wiki.openstreetmap.org/wiki/Proposed_features)

2) Map lots of these features and then wait for other mappers to adopt
the tag. If it has been used thousands of times in many different
countries over a period of several years, then it can be added to Map
Features as a "De facto" tag, even without a vote.

Joseph Eisenberg

(In the future, a better place to discuss changes to
Template:Map_Features:route is
https://wiki.openstreetmap.org/wiki/Template_talk:Map_Features:route)

On 2/19/20, Pierre Béland  wrote:
> Joseph, you deleted recently the link I added to the Map_features wiki page
> for snowmobile routes.  It seems you dont like such schema and want to
> impose your views here.
>
> Snowmobiles routes are as common as bike or hiking trails in nordic
> countries. And the snowmobile wiki page describes it.
> https://wiki.openstreetmap.org/wiki/Tag:route%3Dsnowmobile
> Would you please revert your delete ?
>
>
>
> Pierre
>
>
>    Le mercredi 19 février 2020 04 h 00 min 04 s UTC−5, Joseph Eisenberg
>  a écrit :
>
>  > I have occasionally moved such pages into the user's name space when I
> found them to (by content, if not by name) to be proposals for
> something, rather than a documentation of something already established.
>
> That is fine if the tag has not been used, and the page is written
> like a proposal suggestion. But if the user just wants to tag a dozen
> widgets as Tag:amenity=widget, it is fine to leave the Tag page in
> place, and then add information as needed like "See Also the more
> common tag landuse=widget which has a similar meaning", or "Some other
> mappers have used this tag in a different way, with this differnet
> meaning..." when necessary.
>
> I personally check every new Tag: and Key: page (in English,
> Indonesian or Spanish) every couple of weeks, and I suspect  Mateusz
> Konieczny  and some other experienced wiki users also check the
> Special:NewPages list frequently for the same reason. You can see that
> many of the Tag: and Talk pages on
> https://wiki.openstreetmap.org/wiki/Special:NewPages have been edited
> by more than one user, even the ones that were made in the past month
> or two.
>
> This review effort is not yet happening for the Data Items, and since
> there were >500 created by bot over Christmas (Dec 25-26th), I think
> it's unlikely anyone has reviewed the recently created data items over
> the past few months. Most are content-free (key=value is the only
> property), but some probably need to be checked.
>
> - Joseph Eisenberg
>
>  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Deletion of wiki page contributions Was Creation of "Data Items" by bot for undocumented tags

[Pierre Béland via talk]

Joseph, you deleted recently the link I added to the Map_features wiki page for 
snowmobile routes.  It seems you dont like such schema and want to impose your 
views here. 

Snowmobiles routes are as common as bike or hiking trails in nordic countries. 
And the snowmobile wiki page describes it. 
https://wiki.openstreetmap.org/wiki/Tag:route%3Dsnowmobile
Would you please revert your delete ?


 
Pierre 
 

Le mercredi 19 février 2020 04 h 00 min 04 s UTC−5, Joseph Eisenberg 
 a écrit :  
 
 > I have occasionally moved such pages into the user's name space when I
found them to (by content, if not by name) to be proposals for
something, rather than a documentation of something already established.

That is fine if the tag has not been used, and the page is written
like a proposal suggestion. But if the user just wants to tag a dozen
widgets as Tag:amenity=widget, it is fine to leave the Tag page in
place, and then add information as needed like "See Also the more
common tag landuse=widget which has a similar meaning", or "Some other
mappers have used this tag in a different way, with this differnet
meaning..." when necessary.

I personally check every new Tag: and Key: page (in English,
Indonesian or Spanish) every couple of weeks, and I suspect  Mateusz
Konieczny  and some other experienced wiki users also check the
Special:NewPages list frequently for the same reason. You can see that
many of the Tag: and Talk pages on
https://wiki.openstreetmap.org/wiki/Special:NewPages have been edited
by more than one user, even the ones that were made in the past month
or two.

This review effort is not yet happening for the Data Items, and since
there were >500 created by bot over Christmas (Dec 25-26th), I think
it's unlikely anyone has reviewed the recently created data items over
the past few months. Most are content-free (key=value is the only
property), but some probably need to be checked.

- Joseph Eisenberg

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

Re: [OSM-talk] Forests are mappable - was: Re: OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Pierre Béland via talk]

Hi Mateusz
The link below shows north of Canada areas, where the wood landcover correspond 
in general to Canvec imports. The blank areas are mostly not mapped yet except 
some lakes and 
infrastructures.https://www.openstreetmap.org/#map=5/55.740/-79.804
But for Labrador, the contributors have made the choice to import Canvec 
excluding the wood landcover. If someone wants to test how easy it is to add 
the wood landcover, there is quite some work to do there creating multipolygons 
with inner roles for lakes, cuts for Power lines, etc. 
https://www.openstreetmap.org/#map=9/53.4595/-63.9679 
Pierre 
 

Feb 12 r 2020 13 h 30 min 57 s UTC−5, Mateusz Konieczny wrote :

Hard to say more or verify without getting specific location but I cleaned up 
some places
mangled by badly done forest imports - for example border area that was hit 
with multiple
low quality imports.

But it sounds exactly like https://www.openstreetmap.org/user/Abbe98/diary/28368
that was solved by splitting unreasonably large relation in parts (by deleting 
it
and remapping)

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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Pierre Béland via talk]

On Feb 11  18 h 49 min 26 s UTC−5, Mateusz Konieczny via talk wrote: 

>  ??? just do not create unreasonably large multipolygons (or split existing, 
> possibly undo import if it makes area uneditable and do it right).
Your answer seems to be that it is possible to map appropriately with the 
current rules. Or maybe not, but anyway, let simply ignore these areas, not 
find appropriate solution to add these areas  to OSM. For north of Canada 
alone, the superficy is closed to the size of Europe.

Your answer about polygons is simply a spin rethoric form (une pirouette) to 
ignore the problem. Should we rename this project OpenEurope ?
Pierre 
 

Le mardi 11 février 2020 18 h 49 min 26 s UTC−5, Mateusz Konieczny via talk 
 a écrit :  
 
 


Feb 12, 2020, 00:07 by talk@openstreetmap.org:

Feb 11, 15:59, stevea wrote :

> Rather than get snarled in counter-examples, let's discuss how OTG isn't and 
> can't be strictly 
> followed in many cases.  It IS followed in the majority of cases, but in 
> those corner cases where 
> it isn't, because it can't be ("nothing" is OTG), must be realistically 
> addressed, likely in our wiki 
> where we state the "rule" today, though going forward much better state a 
> "guideline".  I think 
> we can get there, but it remains under discussion / construction.

I agree with this and I adds some other aspects to take into account below. The 
areas not yet mapped in OSM have characteristics quite different than the 
industrialiased regions / countries. And we cannot realistically count on 
mappers to walk or cycle through huge isolated areas. We cannot expect people 
that figth to survive, that have no good internet connexion to map intensively 
there neighboorhood. And more then mappers, we need to think where we need to 
revise OSM. 

Note that it is not violating OTG. OTG is not "everything must be mapped on 
survey", it means
that direct survey (what is actually existing) overrides official data, 
opinions and desires.

If we could keep the wood landcover outside of OSM, it would greatly simplify 
mapping of such areas and dramatically reduce the Mulipolygons problems where 
huge multipolygons are created with inner for lakes and all the problems 
related to this.

??? just do not create unreasonably large multipolygons (or split existing, 
possibly undo import
if it makes area uneditable and do it right).
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Pierre Béland via talk]

Feb 11, 15:59, stevea wrote :
> Rather than get snarled in counter-examples, let's discuss how OTG isn't and 
> can't be strictly 
> followed in many cases.  It IS followed in the majority of cases, but in 
> those corner cases where 
> it isn't, because it can't be ("nothing" is OTG), must be realistically 
> addressed, likely in our wiki 
> where we state the "rule" today, though going forward much better state a 
> "guideline".  I think 
> we can get there, but it remains under discussion / construction.
 
I agree with this and I adds some other aspects to take into account below. The 
areas not yet mapped in OSM have characteristics quite different than the 
industrialiased regions / countries. And we cannot realistically count on 
mappers to walk or cycle through huge isolated areas. We cannot expect people 
that figth to survive, that have no good internet connexion to map intensively 
there neighboorhood. And more then mappers, we need to think where we need to 
revise OSM. 

In Africa, I have often used ne highres imagery to retrace official imported 
border limits that had been traced prior to the availability of detailed aerial 
imageries.
Also there are remote areas like lake North of Quebec, where we cannot 
realistically go and walk to trace every lake contour or follow thousand of km 
of Power lines (+ bears, mosquitos), and we need some assistance for example to 
trace hundred of thousand lakes like this one (imagery, assisted mapping, 
imports ??).https://www.openstreetmap.org/way/75891758#map=11/61.3877/-73.4622
Mappers dont add wood cuts for roads and map styles take care of this. Could we 
have a similar rule applied for Power lines, rivers and lakes ? And any 
possibility to approach the landcover differently ? Mappers, Schema or 
Developpers problem ?

What can we do to approach more realistically the problems, to establish good 
basis for more mapping to come ?
Yes, let's avoid the problem saying this is the bad Canada imports. Or maybe, 
we should think to revise the OSM schema which is not well adapted for such 
areas.
There exist distinct Landcover layers like on this Maptiler OSM Vectorial Map  
with a distinct Landcover layer
https://openlayers.org/en/latest/examples/mapbox-style.html
If we could keep the wood landcover outside of OSM, it would greatly simplify 
mapping of such areas and dramatically reduce the Mulipolygons problems where 
huge multipolygons are created with inner for lakes and all the problems 
related to this.
Yes the problems must be realistically adressed if we want to progress.
 
Pierre 
 

Le mardi 11 février 2020 15 h 59 min 12 s UTC−5, stevea 
 a écrit :  
 
 On Feb 11, 2020, at 12:05 PM, Mark Wagner  wrote:
> Have you actually been to the US-Canada border?  For thousands and
> thousands of kilometers, it's really obvious:
> https://upload.wikimedia.org/wikipedia/commons/a/aa/US-Canada_border_at_Crawford_State_Park_20130629.jpg
> 
> Even when it's not as obvious as in that photo, there are still
> frequent boundary cairns.  And yes, they're mapped in OSM:
> https://www.openstreetmap.org/node/1997617997

I have been there, and in British Columbia, as is your example.  There will 
always be counter-examples to a claim of "boundaries are not always obvious or 
indicated on-the-ground," (as you did, here, with a cutline in the real world 
some of these being mapped in OSM).  Same with mountain ranges, oceans / bodies 
of water, etc. that have no signage or evidence of them (named as they are) 
being OTG.  Simply stated, there ARE (and always will be) things we map which 
are not OTG, making OTG not a rule strictly followed.

However, we map these anyway, and by the thousand.  My point is that OSM 
shouldn't pretend that the OTG "rule" is absolute, as it isn't.  While I think 
all of us (even its original proponent in 2007, as Mikel stated earlier) agree 
that OTG is "an excellent guideline to be followed where it can be," others 
(Colin, Yuri) here have chimed in or infer that it can't realistically be 
absolute (as it isn't, and it can't).  Me, too.  There seems to be consensus 
that "Independent verifiability" is a crucial component of Good Practice in 
those cases where OTG cannot STRICTLY be followed, as in cases of invisible 
boundaries, oceans without signage, and mountain ranges where we are forced to 
concede "well, everybody simply KNOWS that these are 'The Alps' or 'The Rocky 
Mountains.'"  The solution here is "this (and its correct name) can be 
independently verified, that's "good enough for OSM" even without OTG evidence.

https://wiki.osm.org/wiki/Talk:Good_practice#Supplementing_and_clarifying_the_On_The_Ground_.22rule.22
 has input from Yuri and jeisenberg and I discussing whether unsigned routes 
qualify for this treatment (we can't see them OTG, but we map them anyway, as a 
public agency asserts their existence, though it hasn't signed them well).  
While routes like this are a relatively minor (lesser) concern about OTG, 
broader disc

Re: [OSM-talk] Tag:man_made=embankment

[Pierre Béland via talk]

I think that there is a miss-conception here. If you want to talk about the 
wall the retains the earth, this is the dyke. The embankment is more then a 
wall and is at least as large as the road and made of resistant material.  The 
wiki pages https://wiki.openstreetmap.org/wiki/Key:embankment and 
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dembankment do not accept 
usage of polygones with these tags.
see description of embankments in 
https://www.sciencedirect.com/topics/engineering/highway-embankment
 
Pierre 
 

Le mercredi 15 janvier 2020 13 h 56 min 45 s UTC−5, Yves 
 a écrit :  
 
 You should have read "right side of way" : it's the side on your right when 
you follow the way in its direction.
Yves 

Le 15 janvier 2020 17:59:42 GMT+01:00, Paul Johnson  a 
écrit :


On Wed, Jan 15, 2020 at 10:28 AM 80hnhtv4agou--- via talk 
 wrote:

What does this mean ? “should be tagged on a way drawn with the lower side on 
right side of way direction”

The downhill side of the embankment is to the right of the way. 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] mapping outside Europe

[Pierre Béland via talk]

Eh, I am quite please to realise that the page is now available in 6 languages.

The  first version of the page early 2013 was for the OpenStreetMap response 
North of Mali. But in later discussions, contributors did say that it did also 
represent reality of other African countries. We then collectively decided to 
rename it to highway_tag_africa. 

There are regular mentions on discussion lists about this classification but no 
success using search tools to find references. I will let local contributors 
from various countries respond to your questions about classification and name 
to use.
In one country, the situation can vary a lot from more urban and industrialized 
regions to other regions.  I can tell you that north of Quebec / Canada there 
are vast forestry areas with very low population. Road infrastructures in such 
forestry areas are quite different from the urban areas and I would not 
classify a few hundred km long unpaved and rough road interconnecting various 
other roads as track.See for example the transtaiga highway 
https://www.openstreetmap.org/relation/6625883#map=7/54.104/-73.644
 Pierre 
 

Le mardi 7 janvier 2020 16 h 38 min 39 s UTC−5, Mario Frasca 
 a écrit :  
 
 On 07/01/2020 15:46, Pierre Béland wrote:
> I am the original author of the Highway Africa Tag wiki page.  This 
> page is now widely used outside of Africa (Asia and Latin-America) in 
> areas where it better correspond to the reality of the roads 
> infrastructure.

I see, and I like it.  good job!

but it still only mentions 'Africa'.  How would you describe the 
application range, other than "outside high wages / developed countries"?

my guess for the first sentence would be "Most regions in the world do 
not show the same road network quality as, say, Germany or Canada.  Road 
conditions in such regions do not match the economic and social role of 
the road." then go on with the rest.

which Latin American countries are using this page as a reference? as 
far as you and others here know?
> And pictures have been used to better correspond to the ligther road 
> structures in these areas, which are often unpaved. 

nice pictures indeed.  curious enough, they aren't (yet) linked in the 
Spanish version of the page.  I might find time to do so.

ciao,

MF

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

Re: [OSM-talk] mapping outside Europe

[Pierre Béland via talk]

Hi Mario
I am the original author of the Highway Africa Tag wiki page.  This page is now 
widely used outside of Africa (Asia and Latin-America) in areas where it better 
correspond to the reality of the roads infrastructure.  And pictures have been 
used to better correspond to the ligther road structures in these areas, which 
are often unpaved.  

This image near Butembo, North of Democratic Republic of Congo, cleary shows 
damages to road structures at rainy season. I have experienced the same in 
south-east of Haiti, and observed it often in other countries.

https://twitter.com/pierzen/status/1163096946300653570
There is quite a difference between crowdmapping and community mapping. It is 
easy to bring in thousand of inexperienced contributors. But, if  they are not 
trained and monitored, there will be significant damages to the map.
 regard

Pierre 
 

Le mardi 7 janvier 2020 15 h 05 min 38 s UTC−5, Mario Frasca 
 a écrit :  
 
 On 07/01/2020 14:53, Mario Frasca wrote:
> so you say: just revolutionize the overview for the highway tag, 
> without first reaching a consensus?  or I understood you wrong? or 
> replace the Eurocentric pictures with Panama and Morocco pics? an edit 
> like this will be reverted after 15 minutes! 

ah, no, I see, you suggest to take inspiration from the 
https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa, or the German 
(very complete) overview How-to-map-a.  both pages which I did not know.

quite a bit of work, but who knows we manage to motivate the Latam group 
for this.

will put it on my personal to-do list, but if others from Latam are 
reading here, they can add their comments and ideas.

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

Re: [OSM-talk] [Osmf-talk] Attribution guideline status update

[Pierre Béland via talk]

Hi Nuno, 

How can we react positively suggesting to take care obout OSM attribution ? 
This is an international media and we can benefit by having a bit of fun.

Plus this is Christmas coming soon and we need to think positive !
 You could make tweet to https://twitter.com/BBCTwo   + using OpenStreetMap 
logo image (add @OpenStreetMap as who is on the image) + url link to facebook 
article
 saying
Merry Christmas from the OpenStreetMap community Happy to provide accurate and 
detailed maps to news medias, governnments, research, business, consumers, to 
respond to disasters, etc.  Dont forget - Our New Year Best Wishes to have more 
impact - OpenStreetMap Contributors attribution :)
Then you could invite OSM contributors on the discussion lists to make it Viral 
by responding !
To show OSM diversity, I would be pleased to respond to the tweet.

Bonne année, Pierre Béland, du Québec, Canada, fier de supporter OpenStreetMap.

;)
 
Pierre 
 

Le jeudi 19 décembre 2019 18 h 16 min 44 s UTC−5, Nuno Caldeira 
 a écrit :  
 
 here's another lovely example from BBC TWO using Strava (i can spot the Mapbox 
logo, not the reasonable calculated ©OpenStreetMap contributors). glad BBC 
attributed Google properly. they probably aren't aware it's OpenStreetMap, if 
they can't read the attribution on 
Stravahttps://www.facebook.com/413132078795966/posts/2468472903261863/

On Fri, 1 Nov 2019, 18:59 Nuno Caldeira,  wrote:



On Fri, 1 Nov 2019, 18:05 Simon Poole,  wrote:
 
The fair use point just turned up to illustrate that there are limits on what 
we can expect copyright to do for us (aka the tweets from private individuals 
showing a map excerpt that Nuno pointed to) and there is no point in getting 
upset over that there are such limitations. 

actually Simon those prints indivuals share on social media is sent to their 
emails by the company (as someone pointed after you writing). Strava sends 
emails of OSM basemap to their users without attribution. I been testing Strava 
app today and had a couple of laughts TB. tYhere's even more interesting stuff 
we should take notice when doing the attribution guidance. they use Google maps 
on their android app, the routes they display clearly isn't from their users 
(it's not GPS traces as it is impossible to have no overlaping traces on 
mountain regions). I'm sure these routes are from OSM and I'm gathering 
evidence from my contributions that this is OSM data. I will get back to it 
when I get home and record a video with clear evidence that it is impossible to 
be their users GPS trace or Google Maps (as they do not have data in that 
regions). That could only come from OSM and I'm sure as I added that data and 
weekly monitor the editing and their suggested routes sometimes overlap the 
same route as it displayed different versions of OSM data during the years. 


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

Re: [OSM-talk] Status / Documentation of JOSM Check for Almost for almost right angle buildings

[Pierre Béland via talk]

I have obtained infos about how to run this, filing JOSM ticket 
https://josm.openstreetmap.de/ticket/18171
We first need to select in the Preferences Data Validator Panel the option 
«Show Informational level»Then only data downloaded with selecting a BBOX is 
considered (does not work with Overpass query downloads).

When we click for Validation, reports are classified under-Other
  -> Building with an almost square angle
 
Pierre 
 

Le mercredi 25 septembre 2019 14 h 37 min 59 s UTC−4, Pierre Béland 
 a écrit :  
 
 I can find some references to this subject in JOSM tickets and the definitiion 
of minimum  / maximum in JOSM Advanced paramenters. But I have no success to 
run the tests.

The JOSM ticket https://josm.openstreetmap.de/ticket/16189  discusses about the 
implementation of the Check for Almost right angle with reference to the two 
parameters to control minimum and maximum angles for building polygons to 
detect.
>From JO§M advanced preferences, I see that the two variables have default 
>values.
validator.RightAngleBuilding.maximumDelta=1
validator.RightAngleBuilding.maximumDelta=10
To test this function, I did assure that I have Expert Mode selected and that I 
have angles in building polygons closed to right angle. But Running the 
Validator Check function from the Validation Pannel, I do not see any warnings 
added to the Validation Results.

Could somebody tells me the status of this function and help me to understand 
how to run this function ?
 
Pierre 
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Status / Documentation of JOSM Check for Almost for almost right angle buildings

[Pierre Béland via talk]

I can find some references to this subject in JOSM tickets and the definitiion 
of minimum  / maximum in JOSM Advanced paramenters. But I have no success to 
run the tests.

The JOSM ticket https://josm.openstreetmap.de/ticket/16189  discusses about the 
implementation of the Check for Almost right angle with reference to the two 
parameters to control minimum and maximum angles for building polygons to 
detect.
>From JO§M advanced preferences, I see that the two variables have default 
>values.
validator.RightAngleBuilding.maximumDelta=1
validator.RightAngleBuilding.maximumDelta=10
To test this function, I did assure that I have Expert Mode selected and that I 
have angles in building polygons closed to right angle. But Running the 
Validator Check function from the Validation Pannel, I do not see any warnings 
added to the Validation Results.

Could somebody tells me the status of this function and help me to understand 
how to run this function ?
 
Pierre 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Re : Tagging Governance

[Pierre Béland via talk]

Hi Roland
It would help To better see the structure of
1.main tags2.attributes adding detailed infos To these tags
Also cases like polygons that should not be overlapped when related   To 
landcoverie. Amenity=university vs landuse=retail
Pierre

Envoyé à partir de Yahoo Courriel sur Android 
 
  Le mar., sept. 10 2019 à 6:54 AM, Roland Olbricht a 
écrit :   Hi all,

I have got into the duty to talk about tagging governance on the SotM
and I would like to develop that opportunity towards something that is
rather helpful in the long term.
To ensure that I am on the right track and not unintentionally after a
personal agenda I would like to ask you to comment on the findings so
far listed below.

To encourage a widespread discussion, I have spread this message on
German and French lists as well (these two because I understand the
languages) and will do so in addition on the tagging list. Feel free to
spread this message further as long as you remember to channel back all
feedback.


Imperfect Flow of Information

Although many parts of the OpenStreetMap project are well translated,
the tagging documentation has substantial deficiencies. Over a random
sample of 10 tags the number of declared languages varies between 2 and
18, but only few are complete and up to date (sample: 2 of 10 for
German, 3 of 10 for French).

Another kind of imperfect information flow is that tag definitions can
be changed on the wiki page long after the tag is in widespread use.

The converse case that a tag is introduced without any documentation is
also happening. While this happens by ordinary users usually slow enough
to make sense of the added data, an import or organized edit might be
able to substantially skew the de facto meaning of a tag, regardless
whether it is in widespread use, documented, both, or none.


More Structure needed

The translation issues have been conflated with a different problem:
Different features may look very different between regions. E.g.
highway=primary and highway=unclassfied versus highway=track
need different sets of examples in Germany and the urban US on the one
hand and Iceland or rural Africa on the other. It is easy to mix this
with the translation into the predominant language in the area,
but the tagging challenges in Belgium, Canada, and Niger are
substantially different, although all three countries happen to have
French as official language. Conversely, there is no sane reason to
change tagging rules every block of houses in Brussels.

Additionally, people often have different search terms than the British
English tag names or their translations, and the wiki search engine is
infamous for its bad performance. Having explicit keywords to direct the
attention of a mapper to the list of possibly fitting tags might help.

A substantial problem source of the concept of proposals is
that it interacts with lots of tags in a nontrivial way and is
practically never properly applied to all affected tag definitions.
A proposal currently is an extra page although it should have much more
an impact like a Git commit, grouping changes across various tag
definition pages in a single changeset.


Legitimacy and Governance

What legitimation has a process if only a handful of people have that
have the time to write mails on a mailing list and to write wiki pages
are involved? In particular, if the proposals end up as being full of
contradictions or vague terms and leave necessary answers undefined.
Yet these still are the people that have shown the necessary long-term
endurance to assure maintenance and that do the work. Thus every change
to replace processes with better processes must be geared towards
broadening not narrowing the base of long-term maintainers.

Conversely, I fully understand mappers that are wary of sudden changes
in the rendering or the access to tags in edting software. A lot of
people whould probably appreciate to better understand what happens on
the way from a tag discussion to a final change in the renderer or
editing software. These processes are not secret, but often
under-documented.

Again, the various discussion channels and the lacking information flow
between them contribute to the bad mood. Even worse, the ratio between
people and channels means that evil or just plainly incompetent people
could easily take over some channels and contribute substantially to the
confusion. Good ideas how to redirect people and close down some of the
channels (e.g. wiki discussion pages) might be worth pursuing. On top of
that the wiki history is so much less helpful than what developers are
nowadays used to from version control systems that borrowing methaphors
and paradigms from there to the tag documentation is worth consideration.

This hopefully helps to foster that the authors of the documentation and
the mappers using a tag actually agree on its meaning.


Best regards,

Roland

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

Re: [OSM-talk] Attribution guideline status update

[Pierre Béland via talk]

I agree, this would be more snappy and more international. It woulrd not be 
necessary to translate the attribution for various languages.   By shortening 
the attribution, their would be less excuses to not attribute on the map.

 
Pierre 
 

Le vendredi 9 août 2019 10 h 40 min 27 s UTC−4, Frederik Ramm 
 a écrit :  
 
 Hi,

I wonder if we could perhaps get rid of the "Contributors" mention
altogether.

The term "OpenStreetMap Contributors" is the unwieldy; it just sounds
strange to say "this is a map made by OpenStreetMap contributors" when
what we really want to say is "this is OpenStreetMap". When translated
into German, you would have to say "OpenStreetMap-Beitragende" or, more
correctly, "Beitragende zu OpenStreetMap", which to the un-initiated
sounds a bit strange and kind of dilutes the OpenStreetMap brand by
adding things before or after. I am pretty sure that there are languages
where grammar in fact requires that the "contributors" be placed before
OSM (as in my "Beitragende zu OpenStreetMap" example) and where no
grammatically correct way exists to place OSM first.

I know, OpenStreetMap is not a legal entity and therefore cannot be said
to own the copyright. Then again, "(c) OpenStreetMap contributors" is
not technically correct either, as there are many ways in which you can
contribute to OSM, but only some of them will earn you a share of the
copyright in the map. Someone who contributes to OSM by giving us money,
or writing code, or organising meetups, is not part of the group that
holds the rights in the map.

I would find a simple "(c) OpenStreetMap" better, more snappy, more
recognizable than if we demand that the "contributors" are mentioned.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Microsoft Buildings vs. OpenStreetMap visualization

[Pierre Béland via talk]

While you observe quality problems with imports,  you can contribute to better 
document these problems  with samples of buildings ( list of osm_id  and brief 
description of observations ).
 
Pierre 
 

Le vendredi 2 août 2019 23 h 34 min 17 s UTC−4, AntiCompositeNumber 
 a écrit :  
 
 In my area, it also appears that the detection rate is fairly good. In
my brief look through I found one building where there is no building
and a few buildings that the AI did not find. The rotation issue was
fairly common as well as a general offset from the imagery (This may
be on the Mapbox side, I don't know). The footprints get the general
shape of the building mostly there, but struggle with smaller
sections. Overall, the tool seems to be good at saying "There is a
building here and it's about this big" but is less successful at
identifying the details of the buildings.

On Fri, Aug 2, 2019 at 8:17 PM Jmapb  wrote:
>
> On 8/2/2019 7:24 AM, Darafei "Komяpa" Praliaskouski wrote:
> > Here's a demo by azavea showing how 125 Million AI-mapped buildings
> > relate to 33 Million buildings currently in OpenStreetMap in the same
> > region.
> >
> > https://demos.azavea.com/building-footprint-comparison/#4.4/38.67/-93.93
>
> Thanks, this is interesting.
>
> Browsing the areas I'm most familiar with in NYC (where we had a
> building footprint import from city data in 2013), I find that the
> buildings that are detected by Microsoft but missing from OSM are mostly
> either already demolished buildings (currently mapped as
> landuse=construction), small outbuildings, or simply nonexistent. In the
> cemetery, Microsoft has picked out a few of the more impressive tombs
> and mausoleums. And in one case Azavea seems to have failed to notice a
> building that's been mapped in OSM for years (since the import.)
>
> Browsing more rural areas in upstate NY, I see thousands of unmapped
> buildings, mostly houses, that Microsoft successfully detected -- in
> some cases despite tree cover. The sizes are pretty good and the
> footprints are okayish. Oddly some of them seem slightly rotated, maybe
> a trick of the shadows.
>
> J
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] Way to delete buildings added by specific user, or help reverting?

[Pierre Béland via talk]

This link let extract object edited by this user in the area the day of this 
changeset.http://overpass-turbo.eu/s/KzM 

This shows that builidngs position correspond to presence of buildings but that 
geometry do not correspond to what we observe on the imagery,.  We see that 
buildings are aligned in parallel with no correspondance to the geometry 
observed.

 
Pierre 
 

Le lundi 8 juillet 2019 15 h 57 min 47 s UTC−4, hbogner 
 a écrit :  
 
 My comment was not nice because I snapped after seeing what he/she did.

As a schooled surveyor that kind of neglect and false data is hurting me 
and I have the right to be angry. Maybe to harsh language but that data 
is false data.

Only one building on this map is not the same as the others:
https://www.dropbox.com/s/r3u6tow5qbc7jna/osm-Venko.png
They are copy/pasted all over the map.

This is not the first complaint I got about him/her from Croatian community.

Croatian community does not like false data being entered just to fill 
the map.


On 08. 07. 2019. 21:36, Bryan Housel wrote:
> hbonger, your comment here is not very nice.
> https://www.openstreetmap.org/changeset/56552674
> 
> Reviewing their edits on OSMCha, most of their edits don’t look too bad
> https://osmcha.mapbox.com/changesets/69561377?filters=%7B%22users%22%3A%5B%7B%22label%22%3A%22Venko%22%2C%22value%22%3A%22Venko%22%7D%5D%2C%22date__gte%22%3A%5B%7B%22label%22%3A%22%22%2C%22value%22%3A%22%22%7D%5D%7D
>  
> 
> 
> Maybe you should try being nicer to them and they might care about the 
> map more.  Comments like yours ripple outwards and affect the rest of 
> the OSM project negatively.. Calling some’s edit “bullshit” is not going 
> to get them to draw better buildings.
> 
> Just saying - be nicer, thanks.
> Bryan
> 
> 
> 
> 
>> On Jul 8, 2019, at 2:57 PM, hbogner > > wrote:
>>
>> Hi all
>>
>> Is there a way to delete buildings created by specific user?
>>
>> Some users already complained about 
>> https://www.openstreetmap.org/user/Venko to me for inaccurate mapping 
>> and imaginary mapping. They wrote to him, but he didn't reply or stop.
>>
>> Here is an example on which I just stumbled:
>> https://www.openstreetmap.org/#map=17/45.52874/15.48285&layers=N
>>
>> He copy/pasted one building all over the place.
>>
>> I tried to revert the changeset, but there are too many conflicts.
>>
>> Any suggestions how to fix this mess?
>>
>> regards, Hrvoje
>>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 



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

Re: [OSM-talk] Map of Population Density vs. OpenStreetMap density

[Pierre Béland via talk]

Speaking more generally, 
Populatation is growing fast in Africa and many african countries dont have the 
resources to organize regular census. See the UN Statistics Division record of 
last census by country 
https://unstats.un.org/unsd/demographic/sources/census/censusdates.htm
This means that quality vary from one country to the other and that often we 
lack good info about distribution of population in the various countries.  The 
OSM building mapping projects are often used for population estimates.
 
Pierre 
 

Le samedi 6 juillet 2019 20 h 08 min 09 s UTC−4, Darafei "Komяpa" 
Praliaskouski  a écrit :  
 
 Hi,
On Fri, Jul 5, 2019 at 4:09 PM Jean-Marc Liotier  wrote:

On Fri, July 5, 2019 2:40 pm, Christoph Hormann wrote:
>
> One warning:  All global population data sets that exist are rough
> estimates with usually significant systematic biases and errors.  For
> example in Switzerland the data set you used sees high population
> density in mountain areas with no basis in reality.

Same in rural Senegal. Low-resolution population data I guess.


Can you point to a specific place please?

What would be the population dataset that you would recommend for 
Senegal?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mali

[Pierre Béland via talk]

John some answers about your concerns
We have our own difficulties in countries like Canada to recruit contributors. 
Not surpsingly, for  African communities with more difficult economic 
conditions, they have poor, unstable internet access and less time to 
contribute.  
Problems are multiple in countries like Mali. It is hard to train and maintain 
local communities. Following the school and health faicilities imports in 2014, 
the Mali community has tried to fix bad imports. But has you see there are 
still problems. The government cannot provide detailed data and the community 
organize various trips to collect more precise data. 


If the international community could work with the local community and not only 
organize mapathons discionnected from these communities with too often newbies 
and problems never corrected. Projects disconnected from the african 
communities add burden, inconsistent map, Spaghetti has one contributor 
reported.  

How collectively can we corret that ? We need our partners that organize 
mapathons to revise their policies to bring in Quality.  Also, it would be 
interesting that software editors could catch more rapidly duplicates to 
correct them quickly.

- About Overlapping and duplicate buildings - Tools like Osmose report these. 
Looking for Mali, it seems that it has been cleaned.

- Large Areas tagged as buildingYou can use this query in JOSM (Overpass Query 
Panel). If you cover a large zone in one query, your query might be rejected.  
In this example, it will query building polygons that have a perimeter longer 
then 1,000 meters. Only a few were reported in Mali.

[out:xml][timeout:60];way[building](if: length()>1000.0)({{bbox}}); out meta;>; 
out meta;

regard
 
Pierre 
 

Le dimanche 30 juin 2019 13 h 18 min 55 s UTC−4, john whelan 
 a écrit :  
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  I think the concerns are more to do with how do we clean it up.

The first major concern is  "Working for a mapping project with Apple."  the 
concern here is paid mappers and the quality of their work.
The second is there are a fair number of imports of varying quality.  Most 
schools I suspect are fairly accurate but it would be nice to tie the node to a 
building or an area.  Some hospitals are very definitely wrong the node is in 
the middle of nowhere and yes I have checked different imagery.  This really 
needs local knowledge to sort out.

Much of it is HOT, highways that are mapped to the edge of the task manager 
tile.  So one highway section gets mapped as track, another as unclassified, 
another as path, another as tertiary as different mappers put heir own 
interpretation of what the tag should be.
If some nice person could come up with an overpass that picked out large 
buildings in Africa that should pick out the villages tagged as buildings.
For paid mappers I think we need a code of conduct.
I think there is sufficient infrastructure in Africa three days for local 
mappers.  Smartphones are becoming more common and so is an Internet connection 
albeit driven by social media.
Can we build on this?  Schools need to communicate with parents and other 
schools.  This sort of implies a postal service which in turn implies names on 
streets and house numbers.
My impression is there would be an economic advantage, larger cities already 
have street names.  Could someone do a PhD in the subject which might well mean 
a bit more government.  My personal view is some things are best done by 
governments.  Highways for example.
By the way some mappers seem to be non HOT so if we can pick them out and 
support them a percentage may well be local.
Cheerio John
On Sun, 30 Jun 2019 at 11:24, Andrew Hain  wrote:

Is there any sign of mappers being part of an organised activity or of someone 
having encouraged them to contribute?
--Andrew
From: John Whelan 
Sent: 29 June 2019 23:49
To: talk@openstreetmap.org
Cc: Pierre Béland via HOT
Subject: [OSM-talk] Mali I've been going over Mali adding in missing villages 
and hamlets working in the southern and eastern part of Mali and cleaning up as 
I go.  Adding nodes to highways that cross but have no nodes, adding tags to 
untagged ways etc.  I even try to make sure each village has one highway at 
least leading to it. 

However as I work west I'm coming across areas that have lots of buildings and 
lots of errors.  I've zapped more than a few hundred duplicate buildings.  I 
confess I have not put a comment on every changeset especially when the mapper 
has less than 30 edits.  I'm seeing three buildings mapped on top of each other 
by the same mapper.  One is untagged and its not just once.  Interestingly some 
of the changesets are tagged "untangling the spaghetti" and I have sympathy 
with that mapper.

In particular I'm seeing whole villages marked as a single building=yes, 
v

Re: [OSM-talk] Why we square buildings (WAS: iD invents nosquare=yes for buildings which should not be squared)

[Pierre Béland via talk]

Am 11/05/2019 um 21.09 schrieb Simon Poole:
> Just a general remark on the technical issue that sparked of this
> discussion:  squaring buildings is not primarily about improving data
> quality. Non-square buildings are simply visually annoying when
> rendered, so much that I support squaring them "as a rule" too when it
> can reasonably be assumed that there are 90° angles in the actual
> building outline. But I'm not kidding myself that it improves "quality".
> If we wanted to define quality of building outlines in OSM we would
> probably be talking about deviations from the buildings footprint area,
> average deviations from the outline and so on, any of these could be
> very small even without squaring. Actually, squaring might impact them
> negatively, particularly when the outline is rough, but as said: square
> buildings are just so much easier on the eyes :-).

See some annoying deviations from the building footprints we would prefer to no 
observe on the map
https://opendatalabrdc.github.io/Blog/img/JOSM-TM-4975-Ndorwa-County-Uganda.pnghttps://opendatalabrdc.github.io/Blog/img/Overpass-Kochi-India-Irregular-Forms-Validation.png
 
High ratios of Unsquarred buildings is often an indication of imprecise mapping 
with often significative deviations from the outlines. But, yes this is more 
then worry about squarred buidlings. We should also worry about the general 
problem of deviations from the footprint.  Dark and unaligned Imagery, various 
images with different offsets and inexperience in correcting the offsets also 
contribute to bad mapping. 

An angle deviation of 1-2 degree is surely acceptable. But analysis of mapping 
shows in some areas very high ratio of unsquarred buildings or irrregular Round 
buildings with important deviations. We see the same with Building Imports 
projects. We cannot apply a strict Yes or No rule like for Topology errors. But 
how much shoud we deviate ?  Geography or Pop Arts ? 
Pierre 

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

Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared

[Pierre Béland via talk]

May 20 2019 at 14 h 02 min 51 s UTC−4, Stefan Keller  wrote 
: 
> Trying to get focus back on the thread topic.

> Storing hints like nosquare=yes (or square=no) is not best practice of
> data curation on w worldwide level.
I dont think either that this is the solution.  We have to look where these 
problems come and try to correct from the source.  Adding  such tag will not 
help software tools to identify where we have problems and can create some 
missunderstanding about its meaning. And experienced mappers are more and more 
reluctant to correct inprecise building mapping.

For Newbies, Building Quality Analysis last year this show some Tasking Manager 
projects with some 60% of unsquarred buldings (see 
https://opendatalabrdc.github.io/Blog/#!Database_Quality_Analysis_Tasking_Manager.md).
 
The same problem for the DR Congo Ebola response in november where we had to 
restart mapping Butembo in an emergency response and restrict mapping to 
experienced mappers.

For an editor like iD, it can participate with other solutions like better 
training to assure that Newbies understand what Building tracing really mean 
and give then some feedback, like for example saying before save "You have 10 
over 12 buildings that are unsquarred.  If you dont know how to make 
rectangular buildings, you should ask for help before you continue.  Do you 
want to send data anyway ?"

We have the same problem with some Building import projects and I think that 
this needs to be fixed where it originates, before it goes in the database.  
For newbies, this mean more training and monitoring in particular in the 
context of Mapathons.
For Imports, this mean to analyze carefully and correct the data before the 
Import.
 
Pierre 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Your thoughts on osm.org

[Pierre Béland via talk]

Mar 12, 2019, 5:58 PM by m...@rtijn.org:
  Imagine the openstreetmap.org home page, but without the map.
  What would the home page be about instead? What would be on it?
Why not slightly redesign the front page with a colorfull top ribbon 
 + revising the content to  respond better to the public in general 
    and the contributors (confusion with the users !)
Hierarchical  Top/Down menu would let better structure the content for each 
audience and present more subjects.  Below is a rough design that could be 
improved.
EditHistoryExport

Join the OpenStreetMap Community
- About OpenStreetMap- Getting help to contribute  
  (Where LearnOSM and other material should be listed)
- OpenStreeMap License (OdBL)
- Signup new account- Login with your nickname

OSM Community Workspace
- Projects 
- National Chapters- Communications   - Contributors Diaries (renaming to Blog 
?)
  - help.openstreetmap  - Discussion lists  - Forums  - irc 

Contributor workspace
- GPS Traces- Diary- My Messages- My Profile- My Options
- Disconnect 
Pierre 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] trash racks in front or after waterway=culvert

[Pierre Béland via talk]

In Canada and probably elsewhere,  such structures are also used to control the 
flow of water in culverts and avoid beavers to obstruct the culvert with dams, 
flooding, eroding the roads or various other structures in the area.See   
http://www.nature-track.com/Living_With_Beavers.html 

But I would difficult to make the inventory of such structures in forestry 
areas. 
 
Pierre 

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

Re: [OSM-talk] We need to have a conversation about attribution

[Pierre Béland via talk]

Below is an example of attribution that can be seen even on small devices.
For the maps that I develop, I do take care to add attribution. Testing even on 
my phone, I can see attribution with Portrait orientation but have problems 
with landscape orientation since there are not enough lines. And less problems 
with larger screens,
 For the Compare maps I publish, many layers can be selected simultaneously and 
Attributions adapted to this selection. Note that the bottom layer in the list 
is always showed. If you select two other layers to compare, attribution will 
be showed for all.  But you wont see all if the layers are not 
transparent.https://pierzen.dev.openstreetmap.org/swipe/UAVCompare-Kinshasa.php#16/-4.388971694131782/15.364025875548
I dont think that this is a technical problem and I consider that partners 
should respect this OSM ecosystem by showing they are proud to advertise OSM  
contributors efforts and stop finding excuses to not do.
 
Pierre 
 

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

[OSM-talk] JOSM Hack Trick for DigitalGlobe Premium Dual Images (Avoid automatic switch to high-res at z18)

[Pierre Béland via talk]

For the #ebola2018 OSM Response, OSM-RDC is using DigitalGlobe Premium imagery 
for the Tasking Manager project 5660 https://tasks.hotosm.org/project/5660.
DigitalGlobe Premium superposes two images in this area. The first image is 
clearer and more recent but with lower resolution. Buildings look tiny and it 
is hard to trace precisely. The second image is relatively obscure and 
sometimes have clouds.
We can trace first with high res imagery and later switch to the lower 
resolution to compete the tracing. But
when zooming-in with JOSM, there is an automatic switch from low to high res 
image at the 40 meters scale (zoom 18). 

How to avoid this behavior  and stick with the low res imagery ? 

This is the Hack! We simply create a second TMS entry in the Imagery panel 
using the tms[17] prefix. Using this, the image is stretched when we zoom-in up 
to 40 meters. Even if we have a pixelated image, it is easier to align and 
trace along the building outlines.
tms[17]:https://{switch:a,b,c,d}.tiles.mapbox.com/v4/digitalglobe.316c9a2e/{z}/{x}/{y}.png?access_token=pk.eyJ1IjoiZGlnaXRhbGdsb2JlIiwiYSI6ImNqZGFrZ2c2dzFlMWgyd2x0ZHdmMDB6NzYifQ.9Pl3XOO82ArX94fHV289Pg

see https://twitter.com/pierzen/status/1088904024626249728
 
Pierre 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [HOT] Quality (was: The point on the OSM Response to the DR Congo Nord Kivu Ebola outbreak)

[Pierre Béland]

Yes, Quality should be be integrated at all levels, from Documentation, Editing 
tools, Projects monitoring particularly in the context of Mapathons to catch 
problems rapidly and correct. And  yes validation is the last step, the last 
barrier to catch Quality problems and correct. 

After the experience with Mapathons in the last few years, we are surely at 
this point where we need to revise our global process and suggest where 
improvements would contribute to this Quality Quest.
Bjoern, in a HOT discussion about the Ebola Response  in Butembo, gave us a 
link to some Documentation used in the context of Mapathons.  It is  important 
to propose such documentation specific to 
Mapathons.https://lists.openstreetmap.org/pipermail/hot/2018-December/014667.html
Documentation easily accessible in iD with the ? shortcut is also a good point. 
Such easy access to documentatin should be part of the various OSM editors. But 
it should also focus on specific skills like Trace a building, Correct 
irregular geometry, Adjust the offset of imagery, Classify roads. Links to 
short videos would also greatly help the beginners.
There are projects more complex with aspects such as the density of urban 
areas, imagery quality and offset and it is important to restrict access based 
on OSM experience for more complex projects and this is now possible for the 
various Tasking Manager projects. Taking this step for the Butembo Ebola 
response this week dramatically improved the quality of the data produced. But 
still, I often observed that some occasionnal contributors to Mapathons 
continue to produce some Fantasy buildings more then a year after they started 
editing.
This is indication of how it is important not only to provide good 
documentation and tools to beginners, to restrict more complex jobs, but also 
to better accompany and motivate the OSM beginners. Let's be a community. Let's 
go back to our roots! We should stop to have thousand of one day contributors 
that produce inadequate data that often is not corrected afterward.

Irregular geometries in the OSM database are probably more then 90% of the time 
an indication of incorrect mapping. Highlighting Irregular geometries and 
overlaps in editors such as iD and JOSM would faciliate revision by beginners.  
It could be integrated in the JOSM validation process.  iD could also have such 
a validation process.   

Monitoring of Quality and OSM edits need tools to quickly identify such 
problems. The Overpass and JOSM could provide the possibility to query for 
irregular geometries and overlaps.  Such addition in Overpass would offer to 
the Mapathons the possibility to visually monitor Quality of editing with the 
participants using for example a list of OSM user id's.  This could also be 
used for edition in JOSM.  And imagine the Mapathon participants that view the 
progress on a «Live Quality Map» plus «Quality statistics». This would be both 
motivating and pedagogic.

There were some regression with the Tasking Manager updates for the possibility 
to monitor the users. For example, the Activity and Stats section do not let 
see on the map the squares mapped by a particular contributor. It is then 
uneasy to revise the edits of a specific contributor that do not map 
appropriately. On the other hand, it is now possible to restrict the access to 
Validation.
.
 
regard
 
Pierre 
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Multiple errors in the same location

[Pierre Béland]

Hi Sandor
Let me present the more general context. To represent forestry and lake areas 
of northern countries such as Canada,  Russia, Scandinavia, etc. is more 
complex then it seems. These northern territories are covered by millions of 
lakes surrounded by forests, have islands, with sometimes again small lakes 
inner these islands. There were some imports made, duplicates created trying to 
follow OSM rules, a lot of ctirics and tensions, and less and less contributors 
ready to edit in these areas.

To see the complexity of some relations, look at the relation for Pipmuacan 
Resevoir https://www.openstreetmap.org/relation/381076 where there are 601 ways 
with inner role and 64 ways with outer role. My portable computer memory is 
often stressed trying to update such relaions with JOSM. Notice also that the 
surrouding forest around the reservoir is not yet defined. 

This make me think, Can we find such complex relations in West Europe urban or 
rural areas? And could we reduce the complexity, the burden for mappers that 
contribute to OSM?

It seems that the major problem we are faced with is that rendering sofwares 
need to determine where they apply wood texture and that the developpers try to 
reduce the time to compute the information to represent adequately such areas. 
There were strict rules implemented recently to enforce Mutlipolygon relations.

To follow these rules represents a lot of  burden for small communities (67 
contributors per day in Canada, 504 in Germany).  

I understand that developpers are also limited. But still, we should ask if the 
expectations about the OSM contributors are always realistic enough. 

You want answers how to map. I suggest that the community should look at 
solutions to reduce the burden of mappers. If we could progress in the 
discussion between contributors and developpers and try to look at other 
solutions to map northern territories, I think that this would be fantastic.
It would be interesting to look if some of the burden could be transferred to 
softwares developpers with the objective to reduce the database size, and 
increase coherence and quality.    For northern forest territories, if a 
polygon did trace forests outer limits, could for example softwares establish 
the lakes, natural features, landuse areas, airports, etc which are inner the 
forest and should not be rendered with the forest style ? 

Establish the polygons inside a polgyon and render them after this polygon ? 
Any other solutiojn?
Pierre 
 

Le mercredi 21 novembre 2018 04 h 24 min 20 s HNE, sandor 
 a écrit :  
 
 
Mateusz, this was really a quick and simple answer, probably made on reading 
the title only.

The issue is much more complicated than you can imagine. You could really help 
me (and the original mapper) if you describe your suggestion how to resolve the 
lake and the hole mismatch in the case from the link. More precisely, assume 
the other mentioned problems are resolved but the (newer) lake – hole in forest 
fitting problem. So, how to move/transform these two objects to fit together? 
Further, how to do the same for really large number of cases where a manual 
procedure by me or “wait until it is done by someone else” is, for many 
reasons, unrealistic. Thanks.

  

Sent from Mail for Windows 10

  

From: Mateusz Konieczny
Sent: søndag 18. november 2018 21:12
Cc: talk@openstreetmap.org
Subject: Re: [OSM-talk] Multiple errors in the same location

  

16. Nov 2018 17:06 by sandor...@gmail.com:


When multiple errors appear in the same location the question is what to do?


  

The same as with a single error - fix the problem (how it should be done 
depends on situation) or

  

wait until it is done by someone else.

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

Re: [OSM-talk] Missing country labels on default OSM.org layer

[Pierre Béland]

Sorry, you are right, right mouse (since I did inverse buttons, left mouse for 
me) to show contextual menu. 
The third option in the popup is OSM Tile Dirty.  I sent to the server the last 
local version I have to assure this fix your problem.

I generally display with Firefox and it works well. The web console shows 
instructions sent to the web for dirty.
 ex. GET https://tile.openstreetmap.org/4/2/4.png/dirty

I tried with Chrome. It also works but I have problems if I try to show the 
Development tools.
 
Pierre 
 

Le lundi 19 novembre 2018 19 h 36 min 22 s HNE, Daniel Koć 
 a écrit :  
 
  W dniu 20.11.2018 o 01:12, Pierre Béland pisze:
  
 
  This map I created let's dirty individual tiles when we click an area with 
the left mouse button. 
https://pierzen.dev.openstreetmap.org/osm-pixels/#4/65.333176/-93.885778   

 
 
Did you mean _right_ mouse button? Well, I get only:
 
 
"erreur > "
 
 
with every action, even on z19.

  

 
 -- 
"Excuse me, I have some growing up to do" [P. Gabriel] 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Missing country labels on default OSM.org layer

[Pierre Béland]

Should we say «False News» : ), the name tag is in both relations and was not 
removed recently. I see the labels at levels 3 and 4.  I dont know if it has 
still an impact when we dirty at low zoom levels, but labels reappeared after I 
have dirty the tiles around the area where we see each tag. But no success at 
zooms 5 and 6. 

This map I created let's dirty individual tiles when we click an area with the 
left mouse 
button.https://pierzen.dev.openstreetmap.org/osm-pixels/#4/65.333176/-93.885778 
Pierre 
 

Le lundi 19 novembre 2018 17 h 36 min 27 s HNE, Daniel Koć 
 a écrit :  
 
 Hi,

Does anyone know what happened to the labels of USA and Canada on
standard OSM.org map? I hope we will release new OSM Carto version this
Friday and soon the low zoom levels (z0-z12) could be re-rendered, but
I'd like to be sure if something was not broken till then.

Some time ago I have proposed to render fresh low zoom tiles every
weekend (instead of 2 weeks), so such problems could be found and
repaired faster, but there's still no response from OSMF admins:

https://github.com/openstreetmap/chef/issues/184


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]



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

Re: [OSM-talk] [OSM-dev] Detect and remove sharp angle/spiky configurations on buildings

[Pierre Béland]

 oups, Resending previous incomplete message

Sandor, 
 you are looking only at spikes. My algorithm presented in recent threads on 
the talk list about Building Geometries detection will also detect regular 
geometries that have any irregular edge ( a difference of more then 2 degrees 
).  It cannot distinguish valid irregular geometries, but they are in general a 
small numbers, and most flagged buildings correspond to imprecise building 
traces.

regular polygons-   90, 90, 90, 90
-   90, 270, 90, 90, 90, 90
-  120 * 6 (hexagon)-  135 * 8 (octagon)

refhttps://lists.openstreetmap.org/pipermail/talk/2018-August/081274.htmlhttps://lists.openstreetmap.org/pipermail/talk/2018-September/081392.html
 
 
Pierre 
 

  

Pierre 
 

Le jeudi 18 octobre 2018 09 h 15 min 53 s HAE, SandorS 
 a écrit :  
 
 
Some days ago there was a question on an OSM forum whether such algorithm 
exists and used by some of the OSM users. Honestly I even did not know that 
such an issue exists and probably I am not alone. The reason to that is either 
that the spiky configurations are hardly visible in maps or that robust users 
handle them as a special case when process tiny outgrowths in their data 
generalisation programs. A closer look at the issue has shown that the issue is 
real and rather general. Spiky configurations exist on most of the area 
borders, roads, roundabouts and so on, there is a huge number of them and 
almost all are errors. To provide strong arguments about the former statement I 
have made an algorithm, a simplified version of the tiny outgrowths detection 
and removal, and applied the corresponding program to the OSM UK buildings. The 
algorithm on a certain abstraction level, its use and the processing results 
are described in details in an article here 
https://drive.google.com/open?id=1MaLdnSnc454xKjn3eL95vDQKeoIW8zGU . There are 
around 120K spiky buildings in OSM and out of these 2834 in the UK. In 
addition, the paper presents many examples how the spiky buildings look before 
and after the correction. Also, the paper contains links to the output data of 
the demo/test processing and how these could be used for visual analyses. So, 
if interested, enjoy the paper.

Regards, Sandor.

  

  

Sent from Mail for Windows 10

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

Re: [OSM-talk] [OSM-dev] Detect and remove sharp angle/spiky configurations on buildings

[Pierre Béland]

Sandor,  you are looking only at spikes. My algorithm presented in recent 
threads  about Building Geometries detection will also detect either 
rectangular, ortogonal etc. geometries that have any irregular angle ( a 
difference of more then 2 degrees ).Regular geometry 
- 90, 90, 90, 90

refhttps://lists.openstreetmap.org/pipermail/talk/2018-August/081274.htmlhttps://lists.openstreetmap.org/pipermail/talk/2018-September/081392.html
 
Pierre 
 

Le jeudi 18 octobre 2018 09 h 15 min 53 s HAE, SandorS 
 a écrit :  
 
 
Some days ago there was a question on an OSM forum whether such algorithm 
exists and used by some of the OSM users. Honestly I even did not know that 
such an issue exists and probably I am not alone. The reason to that is either 
that the spiky configurations are hardly visible in maps or that robust users 
handle them as a special case when process tiny outgrowths in their data 
generalisation programs. A closer look at the issue has shown that the issue is 
real and rather general. Spiky configurations exist on most of the area 
borders, roads, roundabouts and so on, there is a huge number of them and 
almost all are errors. To provide strong arguments about the former statement I 
have made an algorithm, a simplified version of the tiny outgrowths detection 
and removal, and applied the corresponding program to the OSM UK buildings. The 
algorithm on a certain abstraction level, its use and the processing results 
are described in details in an article here 
https://drive.google.com/open?id=1MaLdnSnc454xKjn3eL95vDQKeoIW8zGU . There are 
around 120K spiky buildings in OSM and out of these 2834 in the UK. In 
addition, the paper presents many examples how the spiky buildings look before 
and after the correction. Also, the paper contains links to the output data of 
the demo/test processing and how these could be used for visual analyses. So, 
if interested, enjoy the paper.

Regards, Sandor.

  

  

Sent from Mail for Windows 10

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

Re: [OSM-talk] Proximity

[Pierre Béland]

Solutions depend how big is your data.  Overpass count function might be the 
solution if just a one shot calculation.  You would have a query for each type.

If you want to use the power of SQL databases, Sqlite is a «light solution», 
coupled with the DBeaver database tool.https://dbeaver.io/
I used to parse OSM xml with a Python script, but PostgreSQL + PosGIS offers 
more long term development options like for the Quality analysis I did on 
Building geometries 
(https://opendatalabrdc.github.io/Blog/index.html#!Database_Quality_Analysis_Tasking_Manager.md).
  Osmosis (Osm2Pgsql schema) takes care to import OSM/Xml directly in a PostGIS 
database. From there, quite easy to count, filter, analyze data.
 
Pierre 
 

Le samedi 29 septembre 2018 20 h 02 min 10 s HAE, john whelan 
 a écrit :  
 
 Thank you kind sir.  I've got sidetracked into trying to count types of 
buildings.
I used to use VB not for its power but for its development interface.  So much 
easier than using assembler which I started with many years ago.
Apparently I need a datatable to sort a couple of columns, fine but all the 
documentation is for C#.  It still has the nice development interface but there 
are differences.
I know exactly what I want to do but finding the correct syntax makes me feel 
if you know Perl and it can do the job stay with it.
Thanks John
On Sat, 29 Sep 2018, 6:26 pm Frederik Ramm,  wrote:

Hi,

On 29.09.2018 01:59, john whelan wrote:
> I thank Fredrick for his comments as well.  If a more refined solution
> is required then there is enough information given to make a start coding.

I know Perl isn't what people use these days but just to show that it
really isn't rocket science (and doesn't require elaborate routing
engines for that scale) I've made a modified version of the Perl script
and checked it into the SVN directory. That script will take a .osm data
file as input and generate a schematic map like

http://www.remote.org/frederik/tmp/ipswich-busstops.png

(which depicts Ipswich), where nodes are coloured according to their
distance from the nearest bus stop (in this picture, 500 Mercator metres
or more means something gets red).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"


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

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

[OSM-talk] Buildings Geometry Quality analysis - Visualisations by Contributor

[Pierre Béland]

This time I selected areas for 25 Tasking Manager projects completed in August 
2018. OSM buildings extracts for the analysis are for August 30. 

Individual contributors Building Maps are provided for contributors to 
prioritze for validation. These visualisations are usefull to evaluate rapidly. 
It is also possible to import into JOSM for validation / correction.
Irregular geometries indicators show again a great variability of results with 
a minority of contributors mapping less and mapping with less precision. 
Results vary also greatly from one project to the other (ratios from 1% to 61% 
of irregular forms).
This sample contains nearly 400,000 buildings last updated by 2,135 
contributors. A minority of contributors (522) mapped 10.3% of Buildings but 
71.2% of Flagged buildings for revision. On average, 64% of buildings traced by 
this group had irregular forms or topological errors. 

As the visualisations show with current data (Overpass extracts), no correction 
have been done yet since the various project managers moved to other 
priorities. 

See the Blog update on opendatalabRDC
 
https://opendatalabrdc.github.io/Blog/#!Database_Quality_Analysis_Tasking_Manager.md


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

Re: [OSM-talk] Open Location Code and Graffiti

[Pierre Béland]

Mobile phones let geolocate pictures.  Why not simply send a geolocated 
pictures? This would document the graffiti at the same time. 

 
Pierre 
 

Le mercredi 29 août 2018 16 h 57 min 25 s HAE, john whelan 
 a écrit :  
 
 But what is needed to make it work?
Thanks John
On Wed, 29 Aug 2018, 3:59 pm Pine W,  wrote:

Thanks for sharing the idea of reporting problems like graffiti using 
coordinates. For some reason this idea never crossed my mind until I read your 
email. This would have been useful for me on one occasion in particular when I 
was trying to describe the location of graffiti in a public park. I can think 
of other types of situations where coordinates would be more useful than saying 
something like "200 feet north of the iron statue and on the west side of the 
gatehouse, above a path that goes to the creek".

Pine
( https://meta.wikimedia.org/wiki/User:Pine )

On Sat, Aug 25, 2018 at 10:06 PM john whelan  wrote:

It sounds an odd combination but locally you can report Graffiti to the 
municipality and they arrange for it to be cleaned up by the phone company, 
electric company etc.
The targeted electric boxes are often at the back of houses or on stretches of 
highway that have no houses which means describing exactly where they are 
becomes problematical.  200 meters south of the X Y junction on the north side 
of the highway.
When reporting I use JOSM to pick up the street name from OSM then cut and 
paste it into the Web form.  I invariably make mistakes when trying to type in 
names such as Bottriell Way.
So to make this work the municipality and the phone company etc. have to be 
able to recognise the OLC codes.  I probably need to add the boxes as a node 
into OSM initially just those that have Graffiti, some particular ones are more 
frequently covered than others. 
They may have to be transcribed, so do OLC codes incorporate a check digit?
Anyone have any experience with working with municipalities and phone companies 
etc in this way?  Yes Lat and Long would work but might be confusing to people 
who have to work with them, again check digits would avoid transcription errors.
I also need something to generate an OLC code when using JOSM.  I could use 
OSMand but its difficult to cut and paste from one device to another.
Inspiration anyone?
Thanks John___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

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

[OSM-talk] Buildings Geometry Quality analysis and Visualisations for 12 African cities

[Pierre Béland]

I just published a study on the OSM buildings geometry for 12 cities, providing 
indicators and visualisations to help monitor the OSM data in these cities. 
See https://twitter.com/pierzen/status/1034529503740080128
https://opendatalabrdc.github.io/Blog/#!Database_Quality_Analysis_Building_overlaps_and_irregular_geometries_Various_cartographic_projects_comparison.md
 This is part of OpenDataLabRDC initiated by OSM-RDC and Potentiel 3.0 with the 
objective to share with other communities to enhance the OSM database.

Some would say that there are a lot more indicators in Quality tools such as 
Osmose, KeepRight and OSM Inspector.  Our approach is to provide indicators to 
monitor a territory and the Map visualisations to highlight quality problems. 
It would be great if we could have global indicators for an area coming out of 
these tools.

The number of contributors is limited in Africa and the risk is that errors 
created by mapathons while participating to Crisis responses stay has is for 
years.

The buildings geometry and overlaps are problems that are often mentionned. Our 
approach is to identify buildings traced with irregular forms to examine if 
they correspond to the real architecture of buildings or in fact are imprecise 
tracing of buildings. Various factors can contribute to that such as lack of 
details / inprecise imagery for an area, dense urban or unplanned urbanisation 
areas, or simply participation of new contributors to various Tasking manager 
projects without sufficient training and control of data quality by the 
organizers.
Quite surprisingly, the ratio of Irregular buildings vs Total buildings for an 
area vary a lot, from 1.6% in Kisenso, Kinshasa (DR Congo) to 72.4% in 
Victoria, Seychelles. Fo Building overlap errors, we see it varying from 0.2% 
in Accra to 24% in Pointe-Noire, Congo-Brazzaville. 

In fact, the tasking manager instances are good to distribute tasks among a 
great number of simultaneous participants, but for monitoring, management of 
mapathons in particular, we need to find solutions that assure a better OSM 
quality. 

Note that Kinshasa in DR Congo is part of the 12 african cities who started 
recently their participation to Open Cities Africa. This project is part of the 
World Bank’s Global Facility for Disaster Reduction and Recovery (GFDRR) 
program.

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

Re: [OSM-talk] AI detecting of buildings Idle thoughts

[Pierre Béland]

Claire who added these polygons  is a resident of DR Congo. She coordinated 
with me the North-Kivu OSM Response in 2012, coordinating with the UN agencies 
and NGO's in Kinshasa.  She is coordinator of OSM-DRC and coordinator of this 
OSM Response for the Ebola outbreak around Beni, working closely with the DRC 
ministry of health and the humanitarian NGO's. I do support Claire for this 
coordination and other OSM projects in DRC. And we took the decision to use 
this info to spot rapidly the populated areas. «Take time» to look at these 
polygons one by one  (we did) and you will see that they reflect adequately the 
density of housing in these areas.

In may, has Potentiel 3.0 just started to support OSM-DRC for the OpenCities 
project in Kinshasa, we collectively had to reorganize quickly and respond to 
the Ebola Oubreak. This second outbreak in august is in a different region. 
Each time, OSM-DRC volunteers accept to support the responses, to go in various 
towns and organize activies. This is a very dynamic OSM communty that know the 
field. 

Quality is very important for us and we started a project to use topological 
analysis to enhance the quality of OSM.  A first analysis based on the geometry 
of the buildings that I published last week on the hot lis was not commented 
except 1 answer. See 
https://lists.openstreetmap.org/pipermail/hot/2018-August/014529.htmlhttps://opendatalabrdc.github.io/Blog/index.html#!Bulding_Geometry_Analysis_to_Support_OpenStreetMap_Quality_Analysis.md

Pursuing the analysis, I have identified buildings that cross roads or various 
other polygons and cleaned the data.  See 
https://www.openstreetmap.org/changeset/61701721#map=12/-4.3993/15.3556
While we support this response, other OSM contributors in Kinshasa are 
organizing a 3 days Focus group for the OpenCities project with the 
neighborhood representatives to evaluate infrastructures at risk in case of 
outbreaks or floods.
See OpenStreetMap RDC on Twitter
 

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
OpenStreetMap RDC on Twitter

“Focus group avec représentants des quartiers, zones a risque d'inondation et 
d’érosion Kisenso et matete, Kins...
 |

 |

 |





| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Changeset: 61701721 | OpenStreetMap

OpenStreetMap is a map of the world, created by people like you and free to use 
under an open license.
 |

 |

 |



We are highly involved, volunteering for OSM and you should understand that we 
take some critics with a «a grain of salt».
But the contributor Christoph is going a bit far, insulting, expressing doubts 
about skills of OSM valuable volunteers that know the reality on the ground and 
respond in such difficult context. He should use less epithets, stop signing 
«Verifiability my ass...», clean it, realign his «idle thoughts» and make 
excuses to Claire.

Regard 
Pierre 
 

Le jeudi 16 août 2018 07 h 57 min 38 s HAE, Christoph Hormann 
 a écrit :  
 
 On Thursday 16 August 2018, Rory McCann wrote:
> What's funny is that this import was (according to the changeset
> comment) based on "DigitalGlobe extracted building data". A straight
> up import of the original building geometries would probably be (i)
> less contentious (since a building is a building is a building), and
> (ii) more accurate for calculating population figures (a use for
> building data for humanitarian purposes) and (iii) better for OSM
> since lots of buildings is better than landuse=residential polygons.

I found this peculiar as well - the most likely explanation seems to be 
that the quality of building detection and especially of building 
geometry generation (if that is being done at all) is probably quite 
bad and by not using the building data directly you can kind of 
disguise such deficits.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Redactions in North Korea

[Pierre Béland]

Hi Frederik 

GNS data quality varies a lot from country to country, and yes with the 
coordinates rounded which had imprecision.
Adding to that the corean alphabet, the South corean community would probably 
be the best to handle that.

 
Pierre 
 

Le dimanche 3 juin 2018 13 h 13 min 24 s HAE, Frederik Ramm 
 a écrit :  
 
 Hi,

On 06/02/2018 01:11 PM, Frederik Ramm wrote:
> If you happen to have access to material than can legally be used to
> re-add some of the now missing place names, then your help is very
> welcome. 

It has been pointed out to me that there is 1983 document on North
Korean place names by the United States Board on Geographic Names in
North Korea. A Google-digitized, public domain version is viewable online,

https://hdl.handle.net/2027/pst.15364708

and a text-only OCR'd version is also available. But the names are all
in English only, and the coordinates rounded to full arc minutes (i.e.
+/- 1.5km on the ground). It could be good enough to label places you
see on the imagery, but it is certainly not good enough for any kind of
automated processing.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] Remote Sensing / DOP / DIY people

[Pierre Béland]

I dont know what is picavet. But I dont think thatKite, or balloon or similar 
flying objects could cover rapidly and systematically a rectangular area, be 
stabilized and produce images of quality.

The fix wings are still expansive but can produce rapidly very precise 
imageries and elevation models. It would be interesting to examine the 
faisability to develop such a project including both hardware and open source 
software.

 
Pierre 
 

Le vendredi 1 juin 2018 17 h 39 min 06 s HAE, James  a 
écrit :  
 
 cheaper and simpler would be a kite and a picavet system. I was looking into 
building a FPV, but just getting it to fly in a pattern gets expensive 
quickly(even building from scratch)

On Thu, May 31, 2018, 9:01 PM Florian Lohoff,  wrote:


Hi,
is there a Mailinglist for the Technical aspects of DIY Remote Sensing
e.g. Aerial imaging? 

I am talking about Drone/Copter/Autonomous flying like Sensefly Ebee 
and the like.

As a lot of people are not capable of buying of the shelve equipment
like the Ebee it might be interesting to get people together with
their DIY projects. Autonomous Fixed Wings could be build in the range
of 300€ - But then IMHO the hard part starts.

Camera, Georeferencing the GeoTIFFs, creating a WMS service to be
able to use them with Josm etc. Getting together an Open Source
toolchain, docker containers, howtos etc 


Here is a (German) walk through in building a FPV Wing. We wouldnt need
the FPV parts and this size is most likely not capable of carrying a
camera but its a start.

https://blog.seidel-philipp.de/fpv-wing-aus-kopter-teilen-bauen-mit-inav/


For somebody who has dealt with electronics in the past its Buildable
but i am having a hard time getting it actually to fly.

Flo
-- 
Florian Lohoff                                                 f...@zz.de
             UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[OSM-talk] Dynamic OSM - Vanuatu Ambae island of no return

[Pierre Béland]

Some of you might remember the efforts we made in early 2015 to edit Vanuatu 
islands and map in detail to support the humanitarian organizations, this just 
after the yearly Ebola response. Since then, many signals of precarious 
situations in islands in this south pacific area. Quite sad to read this time, 
the Vanuatu government orders permanent departure from Ambae island.

see 
https://www.theguardian.com/world/2018/apr/19/island-of-no-return-vanuatu-evacuates-entire-population-of-volcanic-ambae


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

Re: [OSM-talk] OSM and new Wikipedia map features

[Pierre Béland]

I have seen a lot of these images and I also believe that we wont need these 
static images if we can interface properly between OSM and Wikipedia. We just 
need the recipes for dynamic connections between the two systems :)

 
Pierre 
 

Le jeudi 3 mai 2018 19 h 43 min 38 s HAE, Joe Matazzoni 
 a écrit :  
 
 I found another OSM page directed at OSM-Wikimedia collaboration [1]. This one 
encourages OSM users to add images of OSM maps to Wikimedia wikis as static 
graphics. As such, I wonder if advances in placing dynamic dynamic maps in 
wikis (though mapframe and maplink has made this page somewhat out of date? I 
don’t feel that I have the standing in the OSM community to update such a page…
And please remember to suggest a short list of OSM Help pages that will be 
useful for Wikimedians coming to OSM for the first time to add multilingual 
names. Thanks!  
Joe


[1] https://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia

_


Joe Matazzoni 
 Product Manager, Collaboration
Wikimedia Foundation, San Francisco

"Imagine a world in which every single human being can freely share in the sum 
of all knowledge." 

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

Re: [OSM-talk] OSM and new Wikipedia map features

[Pierre Béland]

Hi Joe

These features are promizing. My observations will be focused on the 
interrelations between OSM and Wikipeda and my perception that OSM contributors 
need more documentation to support Wikipedians.

I was contacted recently by a  Wikipedian who talked to me about the maplink 
feature and was looking how to represent a river (watershed or other 
possibilities). From our exchanges, we saw different possibilities but I could 
not find what to do on the OSM side to use these features. It says that we can 
both represent polygons or lines. Adding wikidata and waiting up to four days, 
I had no success.  Good examples that are working would help.  I have a 
Wikipeda account and also tried to use these features in a wikipedia page using 
mapframe but with no success.

Should we simply add a wikidata and wikipedia will take care. Should we define 
a mapframe in a wikipedia page? Or the two options are available?

The example below shows an OSM relation for a polygon that is well represented 
in Wikipedia.https://fr.wikipedia.org/wiki/R%C3%A9servoir_La_Grande_4#/maplink/0

But adding a wikidata tag to a OSM waterway riverbank about four days ago, I 
only see a  node represented on the wikipedia maplink map. 
https://fr.wikipedia.org/wiki/Rivi%C3%A8re_L'Assomption#/maplink/0
We need more infos on what type of OSM features can be represented in 
Wikipedia. Also, should the wikidata be unique or not in OSM. For example, if I 
represent a municipality with both a relation for the polygon borders and a 
node for the OSM place, where should I place the wikidata? On the relation? on  
the node? On both? Or two different wikidatga iD's? It depends if I want to 
represent the polygon or the node or both?

Territories are also interesting to represent. We often see images in Wikipedia 
but how to make a link to an OSM object in Wikipedia? See for example 
Longueuil, Québec who has two different wikidata for polygon and node. 
Wikipedia maplink shows a node, but not sure this is related to the node 
wikidata.
https://fr.wikipedia.org/wiki/Longueuil#/maplink/0https://www.openstreetmap.org/relation/6948543
https://www.openstreetmap.org/node/252025539 
Pierre 
 

Le jeudi 3 mai 2018 16 h 53 min 21 s HAE, Joe Matazzoni 
 a écrit :  
 
 Hello OpenStreetMap community,I’m the product manager of the Wikimedia 
Foundation (WMF) Collaboration Team. We’ve been working on project recently 
called Map Improvements 2018 [1] that some of you will find interesting. As 
most of you probably know, WMF maps are powered by OSM data. The most 
significant new feature that we’ll be releasing very soon as part of this 
project is map “internationalization”—which means that’s WMF maps will display 
in the language of the user, rather than of the territory mapped. I wrote a 
recent post describing this feature and how it works [2]. 
We’re also about to spread our embedded maps capability (“mapframe”) to 
hundreds of Wikipedias that don’t have the feature now. The 
internationalization release will follow soon after. These should be welcome 
developments for the OSM community, I hope, since they will put OSM-powered 
maps in front of many millions of new users. 
We don’t anticipate that these new maps will put any strain on OSM performance. 
The impact I do foresee—and hope for—is that the new exposure of multilingual 
map data will inspire many more Wikimedians to contribute to OSM. This is 
likely to happen when users start to see, as they will for the first time, that 
names in their language for some features and places are not available.  
I’m writing today to let you know that these changes—and possibly these new 
contributors—are coming, and to ask for any guidance you think I should pass on 
to Wikimedians who might like to contribute to OSM. We plan to write a Help 
page on our end that will pass on some basic advice. And I will certainly link 
to relevant OSM Help pages, including this"Welcome to Wikipedia users” [3] 
page. I’d very much like to get your suggestions for a short list of Help links 
on OSM—pages you think a user coming in to add multilingual names would find 
useful. Also please send your thoughts about any information you think I 
particularly should impart. 
Please post your thoughts and ideas to the project talk page [4]. Thanks for 
your help, and for providing the valuable service you do to Wikimedia 
contributors and readers around the world.  

[1]https://www.mediawiki.org/wiki/Map_improvements_2018[2] 
https://www.mediawiki.org/wiki/Map_improvements_2018#April_18,_2018,_Special_Update_on_Map_Internationalization[3]
 https://wiki.openstreetmap.org/wiki/Welcome_to_Wikipedia_users[4] 
https://www.mediawiki.org/wiki/Talk:Map_improvements_2018
_

Joe Matazzoni 
 Product Manager, Collaboration
Wikimedia Foundation, San Francisco

"Imagine a world in which every single human being can freely share in the sum 
of all knowledge." 



___
talk mailing l

Re: [OSM-talk] Villages with no highways

[Pierre Béland]

My experience from all the humanitarian responses. Yes, it is important to know 
the territory and adapt. 
For the North of Mali humanitarian response in early 2013, people had 
difficulty to identify villages, flooded by water on the available images with 
the rainy season that last 6 months. In desertic regions it is also very 
difficult sometimes to spot houses if images are not clear enough.
For me this offers a good challenge, not to delete nodes but to find houses and 
add to OSM !
And yes, often, there are no roads in small african villages. Also in  some 
villages, we cannot identify what is private, what is public, and people walk 
in all directions. We need to observe an area, understand how it is organized.

 
Pierre 
 

Le dimanche 8 avril 2018 17 h 08 min 47 s HAE, Warin 
<61sundow...@gmail.com> a écrit :  
 
 In Papua New Guinea there are villages without roads ... people there travel 
by foot, plane or boat!

The terrain is such that vehicle roads, even for bicycles, is impractical.

I don't have detailed knowledge of Africa to say if these villages could be 
real or not... but I would hesitate to delete them without that knowledge.
Possibly question the original mapper or a mapper active locally or
failing any of that producing results demote them to locality and await a 
mapper with on ground experience.


On 09/04/18 06:31, Frederik Ramm wrote:
> Hi,
>
> On 04/08/2018 10:26 PM, Frederik Ramm wrote:
>> Not only that, someone has already picked them out:
> Looking a bit more at the list, I wonder if we should maybe delete all
> nodes that
>
> * were imported before 2010 from GNS
> * were never used since
> * have a "fixme=no population estimate available, defaulted to village"
> * and have no mapping in the vicinity
>
> I have the impression that many of these nodes are stranded in the
> wilderness between several, meanwhile-mapped, populated places, and the
> danger of getting lost while trying to reach one of these places might
> outweigh the advantage of having them.
>
> Bye
> Frederik
>


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

Re: [OSM-talk] Power Lines and topological error detection

[Pierre Béland]

Using Roland Overpass query, we can search easily in JOSM witha query for 
simultaenous childs of  1. way with power:line tag and 2. way with no 
power:line tag
child(type:way & power:line) & child(type:way & -power:line)
Then with the Todo plugin, we can revise each individual point and unclip from 
the electric network.

 
Pierre 
 

François Lacombe wrote:
Hi all,Osmose-QA also display such bad connection between power lines and non
power features
http://osmose.openstreetmap.fr/fr/error/16446522057 (item 7040 class 4)

We also have this issue related to unterminated lines like this occurence
(7040 class 2) :
http://osmose.openstreetmap.fr/fr/error/16430655499
https://github.com/osm-fr/osmose-backend/issues/229

It causes a lot of false positive alerts because occuring on T connections
(not only for power lines)
No offense intended towards devs who do a lot of good work anyway :)

All the best

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

Re: [OSM-talk] Power Lines and topological error detection

[Pierre Béland]

thanks Roland, this extract provides a lot of objects (highway, water, natural, 
landuse, etc.) that were clipped to power lines. We could even add low voltage 
power lines that are clipped to high voltage power lines.

I will play with JOSM Search to isolate the nodes that need to be unclipped.
 
Pierre 
 

Le mardi 6 mars 2018 23:30:50 HNE, Roland Olbricht  
a écrit :  
 
 Hi,

 > Various topological errors related to power lines are not detected by
 > OSM editors. Monitoring the High Voltage power network for Quebec I
 > often find nodes connecting crossing waterbody, highways, landuse to the
 > power lines.

FWIW, you can find them with a query like
https://overpass-turbo.eu/s/wLQ

If you want to only get highways, there is still enough to do:
https://overpass-turbo.eu/s/wLR

For practical work in JOSM, you can get power lines and the connected 
objects: paste

way[power=line]({{bbox}});
node(w);
way(bn);
(._;>;);
out meta;

and choose a meaningful bounding box. Please do not do other things than 
disconnecting, because you cannot see to what the other objects are 
connected. But for disconnecting, this should be fine.

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

[OSM-talk] Power Lines and topological error detection

[Pierre Béland]

Various topological errors related to power lines are not detected by OSM 
editors. Monitoring the High Voltage power network for Quebec I often find 
nodes connecting crossing waterbody, highways, landuse to the power lines. JOSM 
validation do not detect these.  I often, it seems that remote mappers forget 
to look sideways in their virtual world.  Also, it is probably possible to 
write an Overpass query to find nodes that intersect this various «incompatible 
worlds».

This made me write this humoristic note. Who knows, this may help OSM 
contributors to remember to look sideways.
Risks of editing nearby high voltage power lines (humour note) 
https://www.openstreetmap.org/user/PierZen/diary/43443 





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

Re: [OSM-talk] OSM SPAM detector

[Pierre Béland]

It would help to add a comment column to motivate flagging changeset/object 
content has a spam (SEO marketing description/infos, etc.).
 
Pierre 
 

Le lundi 5 mars 2018 13:05:41 HNE, Jason Remillard 
 a écrit :  
 
 Hi Dave,
The detector needs to be "trained" on what a spam changeset looks like versus 
what a normal changeset looks like. Training really means programming the 
detector by example. 
Once we have a good set of example changesets, going forward, it will find them 
on its own. 
Rather than having me or Fredrick decide what is SPAM is or not, getting a 
diverse set of changeset from many people will insure that the algorithm is not 
biased relative to where the consensus is in the project. That is why I posed 
this to talk not dev. People that map are needed for this task.
Finally, this is just a software component. It will still need to be integrated 
into final end user tools. By doing the specialized machine learning code 
first, I am hoping to get some collaborators that are interested in integrating 
this into tools that everybody can use. But without the curated changeset list, 
it is going nowhere. Long term, hopefully it will get integrated into several 
tools... 
Jason
On Mon, Mar 5, 2018 at 12:42 PM, Dave F  wrote:

  Struggling to understand this
 If users are expected to send you changeset ids, how does it "detect spam"?
 In what way are users informed of spammy changesets?
 
 DaveF
 
 On 05/03/2018 14:06, Jason Remillard wrote:
  
  Hi, 
 
  This weekend I put together a SPAM detector for OSM changesets. 
 
 https://github.com/jremillard/ osm-changeset-classification
 
  You don't need to be a developer to contribute, send over any SPAM'y 
changesets you come across via a github issue, a pull request, or even an email 
to me. I just need the changeset id. 
 
  The code is currently hitting 99+% accuracy detecting the difference between 
1500 random normal edits and 1500 sketchy changesets that Fredrick shared with 
the talk-us last last week. This is with zero tuning, so it looks like it will 
work well.
 
  Jason
   
  
 __ _
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap. org/listinfo/talk
 
 
 
__ _
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap. org/listinfo/talk



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

Re: [OSM-talk] Privacy concerns - revive some sort of anonymous editing?

[Pierre Béland]

Note that contributors can use any character they want for user_name. This is 
more an anonymous Acronym with values such as "user_999",  "_ bp _", "_ laser 
_", "_ creamy _", "_ rifi _" " R1 ", etc.
 
Pierre 
 

Le jeudi 1 mars 2018 18:18:15 HNE, Toby Murray  a 
écrit :  
 
 Not to rain on your account deletion party... but it may be doing less
than you think. User names get replicated out to anyone who consumes
OSM data. It is in the weekly planet dump files as well as all the
minutely/hourly/daily replication diff files. So your old (now
deleted) user name and your edits are still recorded in thousands of
databases across the globe. I have one on my own computer at home
actually. I use it to help analyze potential vandalism edits as
Frederik talked about.

Toby


On Thu, Mar 1, 2018 at 3:35 PM, Jibix  wrote:
> Hello everyone,
> I've been a contributor of OpenStreetMap for a few year, with a couple of
> different accounts. I got them deleted today and I though it could be
> worthwhile talking about this here.
>
> In our current era of big data, I have been more and more concerned about
> having all my osm edits publicly linked to my profiles, and these profiles
> publicly listing all these positions and places where I've been, also with
> somehow time information and sometimes comments, etc... visible forever by
> anyone, or any bot. I've looked into making the link between all that data
> not publicly visible, but it seems the functionality there use to be for
> that (anonymous editing) is not possible since 2007/2009.
>
> I've read (a good few of the) related e-mails from that time [1], and I
> understand that there was an important ground and a general consensus for
> that decision, despite a minority of voice disappointed by this "security
> rather than freedom" direction being taken.
>
> My humble point of view is that with the important evolution that OSM has
> experienced since back then, it would be a very good thing, if not done
> already, to revisit this issue and find a middle point which possibly was
> not easily feasible at the time but would now be more achievable. For
> instance, if I had a tick box "do not publicly link changes to my account",
> either at account level or at changeset level, but that every user still had
> the possibility to send a message to the author of such edits, and to roll
> them back (even potentially with a procedure for banning users with too much
> anonymous changes rolled back by the community, as the edits-author link is
> not lost, it's just not visible to users, whether registered or not). Then,
> I think, everyone would be happy, or close to? I mean, I think this would
> address both the concerns that led to the decision of disabling anonymous
> editing back in 2007 and the privacy concerns I summarised above.
>
> (At the time it was also mentioned that OSM is all about being a community
> project, and that it was probably inconsistent to allow anonymous
> contributions in that context. In particular, a comparison with Wikipedia
> was made. My opinion on this is that location-related information are in
> general much more privacy-critical than Wikipedia edits are, in particular
> now that you have user-friendly mobile apps for mapping on the go, and
> therefore the comparison is inappropriate.)
>
> I've been looking a bit around to see if there was a plan for developing
> something like that anytime soon, or if it had been implemented already, but
> I couldn't find. I've mailed the support team, who confirmed there is
> currently no way (other than closing an account) to make edits become
> anonymous.
>
> Therefore I'm afraid the only way forward I see to address my concerns is
> the following:
> 1) on the one hand having my past accounts deleted, for the corresponding
> change-sets not to be linked any more to my name or pseudonym. I got that
> done today.
> 2) on the other hand, from now on, to periodically create and abandon
> accounts for keeping editing without a massive correlation of data being too
> easily possible (but even like that it's an unperfect tradeoff).
>
> I'm not sure how much of the community is having concerns similar to mine,
> but I would guess that these can only have gone bigger and bigger since back
> in 2007. As said above, I believe it would be worth having a think about it
> again. (But maybe it has already been discussed again recently, and I didn't
> find out?)
>
> What are your thoughts?
>
> Looking forward,
>
> Jibix
>
> [1]:
> https://lists.openstreetmap.org/pipermail/talk/2007-October/thread.html#18853
>
> --
> Jibix
> favourite webpage of the moment:
> https://degooglisons-internet.org/alternatives?l=en
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] Highway=trunk : harmonization between countries ?

[Pierre Béland]

If we talk of harmonization, we have to look outside of Europe and the major 
industrialized countries. The highway classsification based on infrastructures 
such as motorways and trunk roads is not adapted to the majority of the 
countries or regions. 
In countries or vast regions with no motorway, should we consider primary roads 
the same level as motorways? Or classify as trunk for the renderer?

 
Pierre 
 

Le vendredi 23 février 2018 11:16:45 HNE, djakk djakk 
 a écrit :  
 
 I know that « trunk »  is country-dependent but why not moving it to a 
worldwide definition ? Administrative classification could be moved to other 
tags :)

djakk
Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský  a 
écrit :

Greetings
I'd like to caution against using this system globally. In Czechia, roads are 
formally classified into classes, which influence signage, ref numbers and so 
on. Deploying this system here would make the tag confusing/useless and would 
likely face enormous backlash. I have no problems with using this system in 
countries without a clearly defined road classification, but please don't touch 
the countries where there is no doubt about what class any given road is.Happy 
mapping!
On 22 February 2018 at 16:20, djakk djakk  wrote:

Hello, 
I totally agree with you, the definition you provide, administrative-free, 
tends to the same osm map between countries.  
djakk
Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien  a 
écrit :

Landing on this discussion several months late. I've just heard of it
by reading a wiki talk page [1].

Since 13 February 2009, the wiki [2] criticises highway classification
as problematic/unverifiable. This has also been subject to a lot of
controversy (and edit wars) in my local community (Brazil), especially
regarding the effect of (lack of) pavement.

In trying to achieve greater consensus some years ago, I decided to
seek opinions elsewhere and finally I arrived at this scheme [3] which
I think is very useful, if not perfect yet. It can be easily
summarised like this:
- trunk: best routes between large/important cities
- primary: best routes between cities and above
- secondary: best routes between towns/suburbs and above
- tertiary: best routes between villages/neighbourhoods and above
- unclassified: best routes between other place=* and above

For example, the best route between two villages would be at least
tertiary. So would be the best route between a village and a town or a
city. Parts of this route might have a higher class in case they are
part of a route between more important places.

It surely raises the problem of determining optimal routes. Maybe a
sensible criterion would be average travel time without traffic
congestion. A number of vehicles may be selected for this average -
could be motorcycle+car+bus+truck, or simply car+truck.

Early results in my area [4, in Portuguese] seem promising and have
produced more consensus than any previous proposals. To me, this
method seems to:
- resist alternations in classification along the same road
- work across borders (where classification discontinuities are
expected because each country is using different classification
criteria)
- account for road network topology
- work in countries with mostly precarious/unpaved roads or
without/unknown official highway classes
- work between settlements as well as within settlements

Borderline cases are probably inescapable in any system that does not
use solely criteria that are directly verifiable - from the ground, or
from the law. Maybe, in certain developed countries, the system is so
well organized that merely checking signs/laws is sufficient. That
does not mean it is like that everywhere on the planet.

OSM has so far received a lot of input from communities in developed
countries (mostly Europe, North America and Australia) and hasn't
given much attention to less developed/organized countries. What comes
closest to this is what the HOT Team does, but the judgment of road
classification one can do from satellite images in a foreign country
is much more limited than the criteria that have been raised in this
thread so far.

I wouldn't endorse tags such as maxspeed:practical due to lack of
verifiability (it should be obvious that different types of vehicles
would achieve different practical speeds). It is better to use the
legal speed in maxspeed=* and describe the practical reason for a
lower speed using surface=*, smoothness=*, and, who knows, maybe the
not yet approved hazard=* [5] (though that is intended for signed
hazards, not subjective/opinionated hazards).

For the sake of long-term sanity, I also wouldn't mix the purpose of
one tag with the purpose of other tags. To describe the surface, there
is surface=*, smoothness=* and tracktype=*. To describe access rights,
there is access=*, foot=*, bicycle=*, motor_vehicle=*, etc. To
describe legal speed, maxspeed=*. To describe curves, there's
geometry.

Purpose, perhaps, is the main issue. What is the purpose o

Re: [OSM-talk] Tool for tag tracking

[Pierre Béland]

Thanks mmd and Roland, I was able to test it. 
Since these new queries extend the type of actions to report, 

Should there be a an action subtype that reports either tag or geometry only 
actions ?
det_action = [tag_create, tag_modify, tag_delete, geometry_create, 
geometry_modify, geometry_delete]
This new query on the test server reports action=deleted when and object is 
simply modified to remove all tags.See https://overpass-turbo.eu/s/uJ8
 
Pierre 
 

Le vendredi 12 janvier 2018 12:35:25 HNE, mmd  a écrit : 
 
 
 Am 12.01.2018 um 14:51 schrieb Pierre Béland:
> Hi Roland. Great additions again.
> 
> I cannot access https://dev.overpass-api.de/api_new_feat/ to test.
> 
> Hi have the message Forbidden, You don't have permission to access
> /api_new_feat/ on this server.
> 

Please disregard any line starting with "{{data:overpass,server". Those
are only needed for overpass turbo to know which Overpass server to use.
You should try one of the following query shortlinks as per Roland's
post instead:

https://overpass-turbo.eu/s/uF2
https://overpass-turbo.eu/s/uF4
https://overpass-turbo.eu/s/uF7
https://overpass-turbo.eu/s/uFa


-- 




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

Re: [OSM-talk] Tool for tag tracking

[Pierre Béland]

Hi Roland. Great additions again.
I cannot access https://dev.overpass-api.de/api_new_feat/ to test.

Hi have the message Forbidden, You don't have permission to access 
/api_new_feat/on this server.

 
Pierre 
 

Le vendredi 12 janvier 2018 00:33:33 HNE, Roland Olbricht 
 a écrit :  
 
 Hi,

for the sake of completeness, I would like to give a preview what is in 
the development for Overpass API:

Similar to this one

> https://help.openstreetmap.org/questions/54268/search-for-objects-created-after-a-certain-date-with-overpass

you could nowadays search with https://overpass-turbo.eu/s/uF0
for all highways that have changed since the beginning of the year in 
and around Antwerp:

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
out geom;

I suggest the "out geom" mode over recursing to the nodes. Overpass 
Turbo can handle both, but the "out geom" means that there is exactly 
one item per object in question. No unchanged nodes get involved.

The above result is bloated by objects like
https://www.openstreetmap.org/way/469659128/history
It has no change to its highway value but just lost the unrelated tag 
"horse=no".

Here comes a feature in the staging area for the next version into play. 
We do not ask for all changes but just for changes that affect the tag 
"highway": https://overpass-turbo.eu/s/uF2

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:t[highway]);
out geom;
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

The line "compare(delta:t[highway]);" reads as: keep only objects that 
have changed in the value "t[highway]". The last line is a directive to 
execute the query on the development server.

We could even drill down further and retrieve only objects that have 
been created or deleted: https://overpass-turbo.eu/s/uF4

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0);
out geom;
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

This is admittedly hacky and the final implementation might have a more 
straightforward term. The condition for "compare" always evaluates to 
the empty string for non-existing objects. And for existing objects to 
"0" as we just have specified, hence it can tell apart existing from 
non-existing objects.

Can we separate the deleted from the created objects? Yes,
https://overpass-turbo.eu/s/uF7 delivers only created objects:

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0)
(
  way._(newer:"2018-01-01T00:00:01Z");
  out geom;
);
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

And https://overpass-turbo.eu/s/uFa delivers only deleted objects:

[diff:"2018-01-01T00:00:00Z"];
way[highway]({{bbox}});
compare(delta:0)
(
  ( ._; - way._(newer:"2018-01-01T00:00:01Z"); );
  out geom;
);
{{data:overpass,server=https://dev.overpass-api.de/api_new_feat/}}

Please note that these are not yet in a published release because there 
may come up a reason to change the syntax. If that happens, I will write 
a mail here again. For example, it might be more concise to do these 
tasks with a three argument "changed" condition. But I have not 
evaluated yet whether this leads to a logically sound syntax.

Best regards,
Roland


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

Re: [OSM-talk] finding overlapping buildings

[Pierre Béland]

Hi Frederik, 
I tried with the area I provided as example in Bali. Interesting to learn that 
we can export a group like that to JOSM for editing / correcting.See this zone 
https://www.openstreetmap.org/#map=17/-8.447237794027034/115.40394650097596

As I said in a thread for Maproulette, QA tools such as MapRoulette or Osmose, 
while exporting data, should use a common  tag added to te changeset metadata 
to describe the Coordination QA tools used to spot problems and edit an area. I 
am not sure if only the comment is recognized actually. If so, a hashtag could 
refer to both osmose and the item with something like #Osmose-item-xxx where 
xxx describes the item.
See this JOSM ticket that address transfer of HOT TM tags 
https://josm.openstreetmap.de/ticket/10758and this HOT TM ticket 
https://github.com/hotosm/osm-tasking-manager2/issues/703

 
Pierre 
 

Le mardi 28 novembre 2017 16:17:55 HNE, Frédéric Rodrigo 
 a écrit :  
 
 You can use the export menu to load all the pinned objects into JOSM, by 
using the remote command.


Le 28/11/2017 à 22:11, john whelan a écrit :
> The problem is how do you fix them?  Having something directly in JOSM 
> is useful. They tend to appear in clusters so step one is find the 
> cluster.  Step two is sort the duplicates out.
>
> There really is some very poor mapping of buildings and this at least 
> identifies the ones that there should be no disagreement about whether 
> they should be deleted or not.
>
> One day we'll sort out what to do about the very badly mapped 
> buildings that at least two other mappers have referred to as junk but 
> that's another story.
>
> Cheerio John
>
> On 28 November 2017 at 15:46, Frédéric Rodrigo  > wrote:
>
>    With Osmose you can also get only large building intersection by
>    filter on severity
>
>    
>http://osmose.openstreetmap.fr/en/map/#zoom=11⪫=49.9788&lon=8.3169&layer=Mapnik&overlays=T&item=0%2C8300&level=1%2C2&tags=&fixable=
>    
>
>
>    Or addressee the class 2 only.
>    http://osmose.openstreetmap.fr/en/map/#item=0&class=2
>    
>
>
>    Le 22/11/2017 à 02:26, john whelan a écrit :
>
>        >Osmose has an 'overlapping building' option. Top of the list
>
>        I want something to feed into JOSM and not just any building
>        that overlaps by 5%.
>
>        Thanks John
>
>        On 21 November 2017 at 19:49, Dave F
>                
>                >> wrote:
>
>            Osmose has an 'overlapping building' option. Top of the list
>
>            Note: Some building are drawn on top of eachother to
>        produce 3D
>            rendering of multi-storey buildings.
>
>            DaveF
>
>
>
>            On 21/11/2017 23:16, john whelan wrote:
>
>                Can someone describe a method I can locate these in
>            JOSM.  I'm
>                not after crossing buildings but just those that are
>            mapped twice
>                so two buildings with 50% or more overlap.
>
>                Straight duplicates aren't a problem but ones that are
>            drawn
>                twice by two different mappers are.  Yes I know it
>            shouldn't
>                happen but it does.
>
>                Thanks John
>


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

Re: [OSM-talk] finding overlapping buildings

[Pierre Béland]

Wow  again, this time a lot more efficient.  With 29,000 ways, very fast 
Result. 
I did not believe it since only perfect duplicates of buildings were selected. 
This was done by a new contributor that did participate to a geoweek mapathon 
responding for the Volcano emergency in Bali. He did use JOSM and was probably 
not trained enough to look at Validations results from JOSM. At least, he 
should have spot these duplicates of nodes+ways. In less then two weeks this 
contributor edited almost 25,000 JOSM objects (ie, nodes, ways or relations). A 
good prospect but quite important to correct rapidly of new contributors 
working so intensely. 
see this zone 
https://www.openstreetmap.org/#map=17/-8.447237794027034/115.40394650097596
Looking at this Bali area, I saw many new contributors quite motivated and who 
added a lot of buildings. But it seems not enough monitoring from the 
organizers. This tool can surely help.
 An other interesting aspect with your scripts, you let us learn how to make 
such scripts.
regard

Pierre 
 

Le mardi 28 novembre 2017 15:13:22 HNE, Mike Thompson  
a écrit :  
 
 John, Pierre,
I made some improvements to the select duplicate buildings script. It now uses 
a spatial index, which makes it a lot faster on large datasets. It also now 
uses the actual area of the buildings and their intersection, as opposed to 
their bounding boxes. I will work on your other requests, but may not have a 
lot of time for the next few weeks.
Mike
https://github.com/MikeTho16/JOSM-Scripts

Select Duplicate Buildings 
Selects duplicate, or near duplicate, area buildings in JOSM's active 
datalayer.A "near duplicate" is a building whose area overlaps another 
building'sarea by more than 50%. Only the first building encountered of an 
overlapping pair is selected. This is done so the issue does not have to be 
looked at twice. The selected buildings are added to the current selection.  
Currently only works with buildings that are ways (not multipolygons).
To Run:* Install JOSM's Scripting Plugin (only necessary once)* Place file in a 
convenient location on your system (only necessary once)* Click "Scripting" (on 
top menu bar)* Click "Run"* Click "..." button and select the script file.* 
Click "Run"

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

Re: [OSM-talk] finding overlapping buildings

[Pierre Béland]

John Whelan saying> I wouldn't like to say I specialize on validating 
maperthons so much as do clean ups in areas> where they have left their foot 
print.

Sorry, I wanted to say you have a lot of expertise with validations, and yes 
ending up cleaning after big mapping operations with new contributors.
Newbies often trace buildings and such validations should help organizers to 
monitor and assure errors are corrected.
 
Pierre 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] finding overlapping buildings

[Pierre Béland]

I am not sure what is already included in JOSM validations, but with orthogonal 
and Duplicates, we cover most of the  newbies tracing buildings problems that 
we can automatically spot analyzing the data. 
Others would be about dimensions that exceed normal building size, this 
including big institutions, shopping centers etc.
- Maximum area size considered as building 
- Maximum length ( we dont want one cm x few km)
Newbies often badly interpret imagery which brings in coverage or accuracy 
problems. We cannot identify all problems with these test  but I think that the 
tests we covered so far should identify most of these problematic 
contributions, helping to concentrate on contributors with most of the problems.
John who specializes on Validation of Mapathon might see other aspects to look 
at.
 
Pierre 
 

Le vendredi 24 novembre 2017 20:12:04 HNE, Mike Thompson 
 a écrit :  
 
 I have a fix for the speed issue, but need to test before posting. There is 
also bug with how the overlap is computed.  Do you want both tests in the same 
script? I could include "building ways with unclosed area", anything else?
On Fri, Nov 24, 2017 at 4:14 PM, Pierre Béland  wrote:

Ok
for the script, I simply commented the console print message and it does work.

Great if developpers could collaborate to improve this as a Building Validation 
plugin. It could include other features such as building ways with unclosed area

 
Pierre 
 

Le vendredi 24 novembre 2017 18:03:48 HNE, Mike Thompson 
 a écrit :  
 
 On Fri, Nov 24, 2017 at 3:43 PM, john whelan   wrote:

> For a small number it works well.  When faced with a sample with a thousand 
>buildings it takes a little longer.I will work on speeding it up.  It this 
>proves useful to the community, I may try and make it into a plugin (to also 
>include the SelectNonOrthogonalBuildings function), which should be faster.  
>Advice from experienced JOSM developers welcome on this matter.

> So thank you kindly sir.You are welcome.  Glad to be able to help out.  

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

Re: [OSM-talk] finding overlapping buildings

[Pierre Béland]

Ok
for the script, I simply commented the console print message and it does work.

Great if developpers could collaborate to improve this as a Building Validation 
plugin. It could include other features such as building ways with unclosed area

 
Pierre 
 

Le vendredi 24 novembre 2017 18:03:48 HNE, Mike Thompson 
 a écrit :  
 
 On Fri, Nov 24, 2017 at 3:43 PM, john whelan  wrote:

> For a small number it works well.  When faced with a sample with a thousand 
>buildings it takes a little longer.I will work on speeding it up.  It this 
>proves useful to the community, I may try and make it into a plugin (to also 
>include the SelectNonOrthogonalBuildings function), which should be faster.  
>Advice from experienced JOSM developers welcome on this matter.

> So thank you kindly sir.You are welcome.  Glad to be able to help out.  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] finding overlapping buildings

[Pierre Béland]

Great
Thanks Mike. I installed both plugins.

Here is my experience with the installation. To add the Scripting button on the 
Main Menu, I went to the Plugins section and installed the Scripting plugin. I 
was then able to follow your instructions to install and run 
SelectDuplicateBuilding.js and SelectNonOrthogonalBuilding.js

Before we run the script, I suggest to load buildings for a small area. Up to 
500 buildings, it is ok for me. Then delay increase rapidly if I move to 1,000 
- 2,000 buildings and more. With Windows 8.1 task manager, I could see that 
Java was running. I just had to wait for completion of the task.
Running  SelectNonOrthogonalBuilding.js on Windows 8.1 with Java 8.0 1210.13
Error message is
Failed to execute the script file
Error message:ReferenceError: Console is not defined 
SelectNonOrthogonalBuilding.js#42
At:line 42

regard
 
Pierre 
 

Le vendredi 24 novembre 2017 15:39:30 HNE, Mike Thompson 
 a écrit :  
 
 Pierre,
Here is a script to select buildings that are not square (not orthogonal):
https://github.com/MikeTho16/ JOSM-Scripts
SelectNonOrthogonalBuilding.js   

To Run:* Install JOSM's Scripting Plugin* Place above file in a convenient 
location on your system * Click "Scripting" (on top menu bar)* Click "Run"* 
Click "..." button and select this file.* Click "Run"
Selects building which are not orthogonal, that is buildings where all corners 
do no measure 90 degrees, with the following exceptions:   * Inline vertices 
(angles of 180 degrees) are ignored.   * Regular polygons are not selected as 
these are likely to be approximations of circles or otherwise valid.   * There 
is a tolerance of +/- 1 degree.   
The selected buildings are added to the current selection.
Mike  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Directed Editing Policy

[Pierre Béland]

There is a constant increae of organized contributions from Task Managers on QA 
tools and I agree that this policy should include these various organized 
contributions.

There should be a goal assure the follow-up of these various projects to assure 
a better collective coordination of the mapping.
I am not sure that we could effectively have all organizers of Events create a 
wiki page. But organizers like for example the Geoweek, that invite to create 
local events should have a wiki page well documented. A section could be added 
to list the specific events + who organize them. 
The Changeset database is the place where we should be able to follow the 
various mapping projects. There is actually no common way to document the QA or 
TM host, the specific project and the various events connecting to the various 
projects. To document how these various coordination tools should be reported  
on the changesets would facilitate the follow-up.
Actually, not all instances of the Tasking Manager add an hashtag to document 
the host and project no. For QA tools, specific projects / missions are not 
documented either. 

 
Pierre 
 

Le mardi 21 novembre 2017 21:21:55 HNE, Yuri Astrakhan 
 a écrit :  
 
 While this might not have been the intention, the

  >  b) directed by a third party exactly what and how to contribute to 
OpenStreetMap

can be applied to any "challenge style" sites such as the MapRoulette or 
Osmose.  I think there should either be a clarification about this, an 
additional discussion with the community, or a specific exclusion.  I know that 
the preamble is talking about paid editing, schools, and mapping events, but 
the text below it seems to have a wider scope.
penstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What would make MapRoulette better?

[Pierre Béland]

For JOSM

See this JOSM ticket that address transfer of HOT TM tags 
https://josm.openstreetmap.de/ticket/10758and this HOT TM ticket 
https://github.com/hotosm/osm-tasking-manager2/issues/703
 
Pierre 
 

Le lundi 20 novembre 2017 16:49:39 HNE, Bryan Housel 
 a écrit :  
 
 Hey Martijn, it’s currently possible to send comments and hashtags to iD (they 
can be sent as two different parameters, or just embed the hashtags in the 
comments like the task managers currently do).  It’s not possible to set other 
changeset tags, but it is something I could add if there is a good use case for 
it.

Thanks, Bryan



> On Nov 20, 2017, at 4:44 PM, Martijn van Exel  wrote:
> 
> Hi Pierre,
> 
> That is a good idea and there are already some ‘hashtags’ that MapRoulette 
> sends to JOSM. I don’t know if this is possible in iD as well. I think it is 
> something that could be improved upon. Perhaps with changeset tags (is that 
> what you are suggesting?)
> 
> Does anyone know if JOSM and / or iD support ‘sending’ changeset tags through 
> remote control / the querystring?
> 
> Martijn
> 
> --  
> Martijn van Exel
> 
> On November 20, 2017 at 2:00:36 PM, Pierre Béland (pierz...@yahoo.fr) wrote:
>> Hi Martijn
>> We see an increase of coordinatead actions via QA and TM tools. But this is 
>> not systematically  
>> documented on the Changeset metadata. For QA tools, sometimes we see in the 
>> comments  
>> reference to MapRoulette or other tools.
>> It is possible for these tools to transfer infos to editors such as iD and 
>> JOSM. It would  
>> be good that tags are transferred to the editors to better document the 
>> coordinated actions.  
>> For TM tools, it could be host and project_no / Title. For QA, it could be 
>> host and project.  
>> For Maroulette this could beQA=MaprouleteProject=XXX where XXX corresponds 
>> to a particular  
>> challenge.
>> 
>> Pierre
>> 
>> 
>> Le lundi 20 novembre 2017 15:50:21 HNE, Martijn van Exel a écrit :
>> 
>> Marc,
>> 
>> Good point and something that has come up often.
>> As Joost mentioned in a reply, the easy solution for this is, as a challenge 
>> owner, to split  
>> up the challenge into regional chunks and label them as such.
>> 
>> The new version will have ‘filter by current map bounds’. I’m not quite sure 
>> how to best  
>> do this yet. One solution would be to filter by challenge ‘centroids’ 
>> (simple), another  
>> would be to consider whatever challenge has at least one task within the 
>> current map bounds  
>> (harder). What would be your idea about this? Others with an opinion?
>> --
>> Martijn van Exel
>> 
>> On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com) wrote:
>>> The possibility to work more locally. E.g. there is a project to add
>>> missing roads in Belgium, I would really like to see only the "issues"
>>> within let say 20km of my house (an arbitrary point I can set).
>>> 
>>> m.
>>> 
>>> On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
>>>> Hi all,
>>>> 
>>>> For those who have used MapRoulette or at least have a good understanding 
>>>> of
>>>> what it does: what would be the *one top thing* for you that would make it
>>>> better?
>>>> 
>>>> I am asking because I am working on a new major release.
>>>> --
>>>> Martijn van Exel
>>>> 
>>>> ___
>>>> talk mailing list
>>>> talk@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk
>>>> 
>>> 
>> 
>> 
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What would make MapRoulette better?

[Pierre Béland]

Martin,
Yes I suggest to add tags to the changeset metadata. On the HOT discussion list 
and the Github Tasking Manager project, you should find discussions about this. 
Yes, it is possible to send these tags with the remote control.
 
Pierre 
 

Le lundi 20 novembre 2017 16:45:02 HNE, Martijn van Exel  a 
écrit :  
 
 Hi Pierre,

That is a good idea and there are already some ‘hashtags’ that MapRoulette 
sends to JOSM. I don’t know if this is possible in iD as well. I think it is 
something that could be improved upon. Perhaps with changeset tags (is that 
what you are suggesting?)

Does anyone know if JOSM and / or iD support ‘sending’ changeset tags through 
remote control / the querystring?

Martijn

--  
Martijn van Exel

On November 20, 2017 at 2:00:36 PM, Pierre Béland (pierz...@yahoo.fr) wrote:
> Hi Martijn
> We see an increase of coordinatead actions via QA and TM tools. But this is 
> not systematically  
> documented on the Changeset metadata. For QA tools, sometimes we see in the 
> comments  
> reference to MapRoulette or other tools.
> It is possible for these tools to transfer infos to editors such as iD and 
> JOSM. It would  
> be good that tags are transferred to the editors to better document the 
> coordinated actions.  
> For TM tools, it could be host and project_no / Title. For QA, it could be 
> host and project.  
> For Maroulette this could beQA=MaprouleteProject=XXX where XXX corresponds to 
> a particular  
> challenge.
>  
> Pierre
>  
>  
> Le lundi 20 novembre 2017 15:50:21 HNE, Martijn van Exel a écrit :
>  
> Marc,
>  
> Good point and something that has come up often.
> As Joost mentioned in a reply, the easy solution for this is, as a challenge 
> owner, to split  
> up the challenge into regional chunks and label them as such.
>  
> The new version will have ‘filter by current map bounds’. I’m not quite sure 
> how to best  
> do this yet. One solution would be to filter by challenge ‘centroids’ 
> (simple), another  
> would be to consider whatever challenge has at least one task within the 
> current map bounds  
> (harder). What would be your idea about this? Others with an opinion?
> --
> Martijn van Exel
>  
> On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com) wrote:
> > The possibility to work more locally. E.g. there is a project to add
> > missing roads in Belgium, I would really like to see only the "issues"
> > within let say 20km of my house (an arbitrary point I can set).
> >
> > m.
> >
> > On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
> > > Hi all,
> > >
> > > For those who have used MapRoulette or at least have a good understanding 
> > > of
> > > what it does: what would be the *one top thing* for you that would make it
> > > better?
> > >
> > > I am asking because I am working on a new major release.
> > > --
> > > Martijn van Exel
> > >
> > > ___
> > > talk mailing list
> > > talk@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk
> > >
> >
>  
>  
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>  
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] What would make MapRoulette better?

[Pierre Béland]

Hi Martijn
We see an increase of coordinatead actions via QA and TM tools. But this is not 
systematically documented on the Changeset metadata. For QA tools, sometimes we 
see in the comments reference to MapRoulette or other tools. 
It is possible for these tools to transfer infos to editors such as iD and 
JOSM. It would be good that tags are transferred to the editors to better 
document the coordinated actions. For TM tools, it could be host and project_no 
/ Title. For QA, it could be host and project. 
For Maroulette this could beQA=MaprouleteProject=XXX where XXX corresponds to a 
particular challenge.
 
Pierre 
 

Le lundi 20 novembre 2017 15:50:21 HNE, Martijn van Exel  a 
écrit :  
 
 Marc, 

Good point and something that has come up often.
As Joost mentioned in a reply, the easy solution for this is, as a challenge 
owner, to split up the challenge into regional chunks and label them as such. 

The new version will have ‘filter by current map bounds’. I’m not quite sure 
how to best do this yet. One solution would be to filter by challenge 
‘centroids’ (simple), another would be to consider whatever challenge has at 
least one task within the current map bounds (harder). What would be your idea 
about this? Others with an opinion?
--  
Martijn van Exel

On November 20, 2017 at 9:58:40 AM, Marc Gemis (marc.ge...@gmail.com) wrote:
> The possibility to work more locally. E.g. there is a project to add
> missing roads in Belgium, I would really like to see only the "issues"
> within let say 20km of my house (an arbitrary point I can set).
>  
> m.
>  
> On Sun, Nov 19, 2017 at 9:59 PM, Martijn van Exel wrote:
> > Hi all,
> >
> > For those who have used MapRoulette or at least have a good understanding of
> > what it does: what would be the *one top thing* for you that would make it
> > better?
> >
> > I am asking because I am working on a new major release.
> > --
> > Martijn van Exel
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
>  


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

Re: [OSM-talk] How to map alleys in African cities?

[Pierre Béland]

>From discussions since 2013 with various african OSM communities and other 
>continents with similar realities, it appears that this wiki page is quite 
>usefull to help classifiy the highways in these countries.  
The objective was to simplify, clarify how to tag highways. Adding pages by 
country would not faciliate the task, would add confusion.
About Andrew proposition, I dont understand why to use the hierarchy set 
(residential, service) instead of (tertiary, residential). With such 
classification, there is nothing between motorways / primary and residential 
highways.
 
Pierre 
 

Le mardi 14 novembre 2017 22:10:38 HNE, Gaurav Thapa 
 a écrit :  
 
 Youthmappers initiative actually has a very large presence in Africa and in 
particular local mappers of Ghana, Uganda and Nigeria are very active. They 
don't use the talk pages but maybe we can bring them on board to improve 

https://wiki.openstreetmap.org /wiki/Highway_Tag_Africa

or create country specific pages.
 
On Wed, Nov 15, 2017 at 4:15 AM, Andrew Buck  wrote:

Pierre's suggestions are a good guideline in general and I don't have
any disagreements with them.

I did, however want to expand a bit on the idea of when to use service
roads, so here is that...

I for one am in favor of additionally making liberal (but careful) use
of highway=service.

A service road is like a residential road, but is not meant to be used
for "through traffic" but rather as the first or last leg of a longer
journey.  With this in mind, I offer up the following example as a good
guideline (or case study) of how this should look in practice:

Several years ago, I traced the roads in Ibadan, Nigeria.  It was nearly
a blank map when I started so I had complete freedom in deciding how to
classify them (this was years before "highway tag africa").  I started
by just marking nearly everything as highway=residential.  Then after
the whole city was mapped I spend some time just looking at the finished
map and the roads overlaid on the satellite imagery.  After taking in
this "whole city view" for a while I began to see patterns in how the
roads were laid out, and these patterns suggested which roads should be
downgraded to service.

In the case of Ibadan there are little "pocket communities" of people,
separated by streams with a few roads crossing the streams but a dense
network within each community.  So after digesting the map, and seeing
how the town was structured, I decided I would downgrade all the roads
that only served to access buildings within one community, but were not
part of the routing if you were traveling outside of the community.
This lead to a marked improvement in the quality of the map, which you
can see in the two links below.  Although I finished tracing all the
roads, I didn't finish all the classifications, so you can see a good
"before and after" of how much better it looks with proper use of
service roads.

Here is a "before" section where all the roads are left as residential:

  https://www.openstreetmap.org/ #map=15/7.3354/3.9118

And here is an "after" section where I have downgraded local-access-only
roads to service but left the rest as residential.  Notice how much more
clearly you can see the neighborhoods, and also how much easier it is to
follow a route, without having to use a route planning tool.  You can
navigate just by looking at the map.

  https://www.openstreetmap.org/ #map=15/7.3933/3.9598

In the second example above you can actually see some areas of all
residential to the east, so there is a very clear difference between the
two sections.

Obviously every town will be slightly different, but I think this is the
general rule we should follow:

   if you use the road mainly for accessing buildings (even if it is
   a fairly large number of them) but not for long distance travel,
   then the road should be downgraded to service.

After you spend a bit of time looking at the whole town, and keeping
this rule in mind, you will get a good sense of what to downgrade.  Then
it is just a matter of going through and applying it.

Anyway, hope this all makes sense to people.  I had been meaning to
write it up for a while now and this seemed like a good opportunity.
Maybe I will try to go through and finish up Ibadan, I am a lot faster
at this now than I was back then, so it wouldn't take me long.  I will
leave it for the time being so it doesn't break the examples.  If people
think this sounds reasonable, maybe we should grab some before and after
screenshots for the wiki to document this.

-AndrewBuck




On 11/14/2017 03:30 PM, john whelan wrote:
> That seems very sensible.
>
> Thanks John
>
> On 14 November 2017 at 16:26, Pierre Béland  wrote:
>
>> I we follow the Highway Tag Africa wiki page I initiated in 2013, narrow
>> highways should be evaluaed on the type of traffic possible
>>

Re: [OSM-talk] How to map alleys in African cities?

[Pierre Béland]

I we follow the Highway Tag Africa wiki page I initiated in 2013, narrow 
highways should be evaluaed on the type of traffic possible - highway= 
residential in residential areas if at least passable by 4 wheels- highway=path 
if only motorcycles, bicyles and foot traffic is possible.
https://wiki.openstreetmap.org/wiki/Highway_Tag_Africa

The additions made to the wiki page a few months ago about the width add 
confusion. I think that we should simply move this in a separate section giving 
guidance on possible widths that represent the various types of highways.

regard
 
Pierre 
 

Le mardi 14 novembre 2017 16:14:22 HNE, john whelan  
a écrit :  
 
 I'm not even sure if this is the best place to raise this but Africa covers a 
lot of countries.
We have some agreement on how to map highways in general Africa but narrow 
residential highways are a problem.  I suspect highway=residential plus a width 
tag might be best.  
South Africa I think has local mappers who able to resolve any problems but for 
the rest of Africa given the large number of armchair mappers mapping there 
some guidance would be nice.
Some mappers use highway=service generously.
Is it possible to reach some sort of general concenus? 
Thoughts?
Thanks John___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Label language on the Default stylesheet

[Pierre Béland]

Nice, I often had problems while editing or validating in countries with non 
latin alphabet. Will this be automaticly overlayed to the map based on your 
language option ?

 
Pierre 
 

Le mercredi 1 novembre 2017 09:38:15 HAE, Andy Townsend  
a écrit :  
 
 On 01/11/2017 13:28, Oleksiy Muzalyev wrote:
> Still, the OSM map remains unusable on the global scale. For instance, 
> I read an article about the new railroad North-South. I wanted to see 
> it on the OSM map but I could not even find Iran on the map. 

Works for me:

http://www.openstreetmap.org/#map=6/31.887/52.844&layers=T

Best Regards,

Andy


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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Pierre Béland]

For the OSM Geoweek in november, Invitations are made for groups, universities, 
etc. to create their own Mapathon.
I suggest to transform this to an «Awesome OSM Geoweek» with focus on the 
quality of edits, quality of leadership, of coaching of new contributors.  
Otherwise, this will simply be a «Pulse of new contributors», editing for a few 
hours and leaving problems to others afterward and publication of «Big numbers 
of Contributors» that represent minimal impact on number of Contributions but 
significative Quality problems. 

The same with this task. The organizers should tell us what they do to correct 
the situation.
 
Pierre 
 

   Frederik Ramm wrote:
Maybe it is possible to do better QA, improve editing software, or
easily fix the broken data, as suggested in various posts in this
thread, but I'd like to find the root cause of this and work on that.

Why and how did one person or a group of people who apparently lacked
the capabilities to make this activity a success, start it in the first
place? What warnings, what training material, what message of caution
could have led them to seek advice from people with the relevant
experience - or what over-optimistic "everyone can do it, no training
required" message enticed them to carry on recklessly?

Bringing dozens of new people to OSM only to delete (or significantly
overhaul) 99% of their contribution later helps nobody; it causes
unnecessary work for experienced mappers (and the DWG), tarnishes the
reputation of HOT and OSM, and discourages these people (who would have
made a valuable contribution given proper training) from contributing
further.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] Sudden influx of bad HOTosm edits in West Bank

[Pierre Béland]

Bryan Housel wrote:> Many of the untagged ways are from JOSM and that warns 
before uploading as well.and
John Whelan wrote:> Many of the untagged ways are from JOSM and that warns 
before uploading as well.

It is always possible to query Overpass and find such problems.
But if applications such as iD and JOSM did add to the Changesets metadata a 
Warning tag, this could be used by applications such as OSMCHA to filter 
changesets.  
Something like warning=Orphan nodes; no tags; etc.
 
Pierre 

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

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

Hi Frederik
The Overpass query shows me this morning that with your last redaction the 
names are back for the 620 highways.
Thanks
 
Pierre 
 

Le mercredi 11 octobre 2017 13:08:42 HAE, Pierre Béland  
a écrit :  
 
 Re-visiting this changeset I see that of the 620 ways with tag 
"source:name"="geobase.ca", 552 ways have no name restored. See for example way 
32798176 where I validated the name + added source:name Overpass query 
http://overpass-turbo.eu/s/sh6

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

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

Re-visiting this changeset I see that of the 620 ways with tag 
"source:name"="geobase.ca", 552 ways have no name restored. See for example way 
32798176 where I validated the name + added source:name Overpass query 
http://overpass-turbo.eu/s/sh6

Pierre 
 

Le mercredi 11 octobre 2017 11:26:35 HAE, Frederik Ramm 
 a écrit :  
 
 Hi,

On 10.10.2017 03:16, Frederik Ramm wrote:
> I still have the raw data and I'll write a quick script
> that finds these cases and restores the names.

Should be done here

https://www.openstreetmap.org/changeset/52829433

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

Great, thanks Frederik.
 
Pierre 
 

Le mercredi 11 octobre 2017 11:26:35 HAE, Frederik Ramm 
 a écrit :  
 
 Hi,

On 10.10.2017 03:16, Frederik Ramm wrote:
> I still have the raw data and I'll write a quick script
> that finds these cases and restores the names.

Should be done here

https://www.openstreetmap.org/changeset/52829433

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OSM Contributors Outlook - The Pulse of OpenStreetMap Contributors

[Pierre Béland]

I published a Diary where I analyse the OSM Contributions, trying to have a 
different perspective on the data.  I briefly show the results of a Cohort 
analysis of the OSM contributors. These analysis are often used to compare the 
progression of various groups from day 1 of a particular event and analyse 
their behavior for a certain period. They help reveal trends in the data.  For 
OSM, this let observe the big peak of new entries which is followed by massive 
departs the next month. In fact, a majority of contributors do not participate 
more then one day. 
I also review the monthly statistics of Contributors and Contributions with 
contributors Profiles and show the heterogeneity between the vast majority of 
contributors that contribute minimally and at the other extent of the 
distribution, the minority that contribute massively to OSM. 

See https://www.openstreetmap.org/user/PierZen/diary/42470
 
Pierre 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

Thanks 
Pierre 
 

Le lundi 9 octobre 2017 21:16:19 HAE, Frederik Ramm  a 
écrit :  
 
 Hi,

On 10/10/2017 02:54 AM, Pierre Béland wrote:
> Hi  Frederik, as a bad armchar mapper, I have revised  the Quebec
> highway names before redaction, validating names with an acceptable
> source + adding source:name=geobase.ca.

I took some precautions to "save" names; if you have indeed modified a
name then it should not have been affected. If the name stayed the same
and you just added the source tag then I'll probably have killed the
name. I had that on the radar once (check for added source:name) but it
seems I forgot. I still have the raw data and I'll write a quick script
that finds these cases and restores the names.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

Hi  Frederik, as a bad armchar mapper, I have revised  the Quebec highway names 
before redaction, validating names with an acceptable source + adding 
source:name=geobase.ca. After redaction, names are removed + even if I try to 
re-import - review all the conflicts throug JOSM, I loose all my changes! 

Not much time to loose as a bad armchair, I am going outside bicycling ;) 
Pierre 
 

Le samedi 7 octobre 2017 19:50:16 HAE, Frederik Ramm  
a écrit :  
 
 Hi,

On 27.09.2017 21:49, Martijn van Exel wrote:
> That is helpful. Let us know when you have re-executed the analysis and
> posted the results.

http://www.remote.org/frederik/tmp/chdr.details

A new list (CSV file) with way id, coordinates, and country/state/county
information. I've eliminated all objects that have been reported to be
ok, and plan to remove or change the names on these remaining ones. (To
avoid misunderstandings: There's a column in the file that says what I
plan to do, either "change to XYZ" or "delete", but that does NOT mean
"delete the object", just "delete the name tag"!)

I'll start doing that in ~ 20 hours from now.

I'll then redact the versions that carried the "bad" name.

The redaction will also affect a few historic objects that *used* to
have a "bad" name and where the name has meanwhile been changed again,
or where the object has been deleted; these redactions will be of little
consequence.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] A thought on bot edits

[Pierre Béland]

Christoph Hormann wrote:
> a) I am unmotivated to map in areas where imports are in progress or 
> regularly taking place (yes, i am talking about Canada).

We often see such reactions (what is good, what is bad) without any analysis of 
the situation.
Do you know Canada, have you tried to measure the effort to map the millions of 
lakes, the efforts to spot nordic villages, roads, industrie, tourism 
activities spread over a huge territory and where this is not the priority to 
provide new high resolution maps?  

This is quite demotivating for us working hard to map north of Canada to 
continously see such negative messages about our work ;)
 regard

Pierre 


  De : Christoph Hormann 
 À : talk@openstreetmap.org 
 Envoyé le : lundi 2 octobre 2017 12h53
 Objet : Re: [OSM-talk] A thought on bot edits
   
On Monday 02 October 2017, Martijn van Exel wrote:
> I find this discussion and your proposal interesting to explore, at
> least as a hypothetical. Do we know 1) what the volume of bot edits
> is and how it has grown 

No, but i thought as well this would be an interesting thing to study.  
Of course you would need to make some definition of what a bot edit is 
that can be automatically analyzed - which is difficult.  But even a 
hairy definition might allow to identify rough trends.

There is little doubt that the volume of bot edits has grown recently 
but if it has actually grown much faster than the manual editing volume 
overall is not easy to determine.  I mostly look at remote areas and 
there the raise in dominance of automated editing activities is massive 
but the manual editing activity in these areas has always been small 
and sporadic so this is certainly not an observation you can 
extrapolate to the whole.

> 2) how many mappers have actually given up 
> based upon this? 

Again i can only answer this based on my own experience and

a) I am unmotivated to map in areas where imports are in progress or 
regularly taking place (yes, i am talking about Canada).
b) My primary motivation for mapping in OSM is that what i map gets 
improved by other craft mappers so what we produce together is better 
than what each of us can produce on our own.  If the only changes that 
are going to be made to my mapping work after i upload it to OSM are 
made by bots there would be no results from that that would be any 
better than what i could produce on my own because i could simply run 
the bots on my own privately mapped data.

Of course i am certainly not representative for the typical mappers.  I 
would suspect there are probably mappers that would be attracted and 
motivated by an OSM project where bots routinely 'fix' data 
inconsistencies like typos in tags, different spellings of common names 
or automatically orthogonalize building geometries.  But there are 
others who don't like this.  One motivation behind my suggestion was 
that this would allow mappers to embrace bot edits but also allows them 
to reject this and decide they only want to interact with other craft 
mappers and not with bots.

-- 
Christoph Hormann
http://www.imagico.de/

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


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

Re: [OSM-talk] A thought on bot edits

[Pierre Béland]

We often see critics about Bots and import accounts. Should we oppose crafters 
vs Bots? Who are crafters, who are Bots?  I suspect that they often can be the 
same ;) from the few thousand intensely active OSM contributors. And not all 
imports or Bots harm our database content. For an informed decision we simply 
need to know better about these Bots and Imports.  

To compile statististices about the OSM Contributors profiles, I am actually 
going through the http://planet.osm.org/replication/changesets/. Not easy to 
identify Bots and Imports from the Changesets metadata. Before 2012, there was 
no specific account for imports. And since 2012, you often have to read the 
contributors user profile from the OSM API to verify if this is an import 
account since not all use a prefix or suffix with import. 
For Bots, you can try to identify the user name that contains words such as 
Bot, mechanical, repair, fix, etc. But this is relatively imprecise.  You can 
also searh the Changesets metadata to see reference to Bot Edit sessions.
If somebody knows a better way to identify Import accounts and Bots, I am 
interested about that.
 
Pierre 


  De : Martijn van Exel 
 À : Christoph Hormann  
Cc : "talk@openstreetmap.org" 
 Envoyé le : lundi 2 octobre 2017 11h17
 Objet : Re: [OSM-talk] A thought on bot edits
   
I find this discussion and your proposal interesting to explore, at least as a 
hypothetical. Do we know 1) what the volume of bot edits is and how it has 
grown 2) how many mappers have actually given up based upon this? My guess is 
that instead of coming up with a global solution, this could be left to the 
local communities to decide. For example, where I live (USA) there does not 
seem to be as much resistance to automated edits to make such a change 
desirable / necessary. The effect of introducing a new tagging requirement for, 
or even entirely separating out automated edits into a different database, may 
have a different (or even an opposite) effect in communities that look more 
favorably upon these types of edits.
Martijn

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

Re: [OSM-talk] Wheelchair accessibility

[Pierre Béland]

Would it be possible to add accessibility tags to both the bus stops and the 
bus routes? This would inform from where to where there is such accessibility.
  
Pierre 


  De : john whelan 
 À : OpenStreetMap talk mailing list  
 Envoyé le : mercredi 20 Septembre 2017 17h13
 Objet : [OSM-talk] Wheelchair accessibility
   
I was at a presentation yesterday evening about accessibility, well it was free 
coffee what more can I say?
All Ottawa buses have two spaces for wheelchairs.  We map wheelchair accessible 
toilets and other things for the map but we currently as far as I am aware we 
don't include information on things that move.
Should we and how would you do it?
For example I understand in the UK there are problems at many railway stations. 
 Perhaps mapping railway stations as being wheelchair accessible or not would 
be a start.
Thanks John___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Name challenge - what to call the new OSM+Wikidata service?

[Pierre Béland]

Then WiseOM ! No OSM license and neither hotosm Blake ;)
 
Pierre 


  De : Yuri Astrakhan 
 À : winfi...@gmail.com 
Cc : OpenStreetMap talk mailing list 
 Envoyé le : Dimanche 17 Septembre 2017 19h20
 Objet : Re: [OSM-talk] Name challenge - what to call the new OSM+Wikidata 
service?
   
RichardF on IRC suggested "semaptic" >  take the "semantic" word associated 
with wikidata and add moar mapswhich seem to have gained a few support votes 
there.   Does it have any negative meanings in any languages?
On Sun, Sep 17, 2017 at 6:15 PM, Jo  wrote:

SparklyMapData or SparklyDataMap

2017-09-17 23:46 GMT+02:00 Yuri Astrakhan :

One thing we should consider is the domain name.  I doubt we can afford woq.com 
:)
These names were proposedwoq   2wdoqs 
woqs
q936
And these proposed names have OSM in them, so likely are not good according to 
Legalwosm  2wikosmwdosm wikidosm
(P.S. Sorry for double - hit send too fast before fixing the first list)
On Sun, Sep 17, 2017 at 5:45 PM, Yuri Astrakhan  wrote:

One thing we should consider is the domain name.  I doubt we can afford woq.com 
:)
These names were proposedwoq   2wdoqs 
wdosm woqsq936
And these proposed names have OSM in them, so likely are not good according to 
Legalwosm  2wikosmwikidosm

On Sun, Sep 17, 2017 at 5:10 PM, Simon Poole  wrote:

  I believe there is a slight misunderstanding, while remixing 
OpenStreetMap/OSM/etc in various ways may result in cutesy copycat domain names 
they simply do not jibe well with reality. Not only does every single one of 
them weaken the standing of the marks themselves and make is increasingly 
difficult to take action against misuse, they are further uncontrollable 
liabilities for the whole community. I gave the example of OpenWeatherMap, but 
there are others that would be really painful if they ended up in the hands of 
your fav giant tech corp. That said, I'm not sure why you believe the policy 
has broken something, with the exception of a few local chapters, to my 
knowledge, the OSMF has never granted a licence to anybody to use the marks in 
a domain name. As outlined in the FAQ we will be operating a grandfathering 
scheme to legalize such use after the fact so actually making such use legit 
for the first time. And yes: WoQ would be a wonderful name for Yuris service 
and shows that it is completely possible to break out of the old schema of 
simply copying OSM. Simon
  
 Am 17.09.2017 um 15:57 schrieb Yves:
  
So, no OpenSparqlMap, then? :(
 Sad, this policy definitely broke something. 
 Yves 
 
 Le 17 septembre 2017 12:58:12 GMT+02:00, Blake Girardot  
a écrit : 
 Hi,

How does this relate to the new draft trademark policy?

I can't tell from the draft policy, but I believe that OSM at least is
a protected mark, not sure about osm.

But I do think Simone Poole asked the community to stop naming things
with osm trademarks in them or variations on openstreetmap phrase.

Cheers
blake

On Sat, Sep 16, 2017 at 5:11 PM, Yuri Astrakhan  wrote:

 The new service is getting more and more usage, but it lacks the most 
important thing - a good name. So far my two choices are: * wikosm * wikidosm 
Suggestions? Votes? The service combines Wikidata and OpenStreetMap databases, 
and uses SPARQL (query language) to search it, so might be good to reflect that 
in the name. https://wiki.openstreetmap.org /wiki/Wikidata%2BOSM_SPARQL_qu 
ery_service P.S. I know this is the hardest problem after off-by-one and 
caching... talk mailing list talk@openstreetmap.org 
https://lists.openstreetmap.or g/listinfo/talk
 
  
  
 __ _
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.or g/listinfo/talk
 
 
 
__ _
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.or g/listinfo/talk






__ _
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.or g/listinfo/talk





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


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

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

Simon Poole wrote 
Maybe I'm misunderstanding what you want to do, but it would seem as if that 
just amounts to doing the work twice.
After revising 126 elements, I agree with Simon. Let's avoid doing the job 
twice.
Below is an evaluation for Quebec / Canada with a sample of 126 of 1,316 id's 
from Frederik list. I see that we cannot assure in this sample what is the name 
source for 98% of the ways modified.  

Since there are often references to Canvec, I did an Overpass query. It appears 
that 53 ot the 1,316 have the tag "canvec:UUID" and this tag was sometimes 
modified. But without confirmation from chdr it is difficult to assess if it 
did really come from Canvec.
Then, yes, for Canada at least where we have opendata available, let's simply 
redact all the names except the typos that are easily identiable and start 
over. 

   2 typo corrections (ie. place to Place, St- to Saint-)
110 Name added  14 Name revision (it could be adding Street, Avenue, Rue, 
Place, Croissant, etc) I saw one Google artefact where Rue was modified to 
Avenue while Rue is specified on the OpenData source
 
regard 
Pierre 






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

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

Simon Poole wrote

PS: naturally simply assuming that all name expansions are legit is a bit iffy, 
consider Circle vs. Circuit  and other expansions that you often can't decide 
without external sources, I don't know if there are  any such cases in the 
affected data, but it seems to be silly to start wasting time on something that 
is  essentially a non-problem (revert the name to the original and re-expand it 
using current TIGER if possible).

To respect contributors participation, I think that it is important to avoid 
deleting valid contributions.
 Before redaction, what I propose to do for Quebec / Canada :
 I will go through thee chdr list provided by Frederik, and will verify the 
history for the name and add either
source:verify tag=chdr name addition without source confirmationsource:verify 
tag=chdr name typo correction

After redaction, it will be easy to select the redacted ways and add the name 
from legit source.
regard
 
Pierre 


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

Re: [OSM-talk] [Talk-us] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

John,
Once the way names are redacted, I will revise for Québec following the naming 
rules different from the english part of Canada. ToDo / JOSM should help for 
this.
regard 
 
Pierre 

john whelan wrote :


I suspect Jamie could wave a magic wand for Quebec.
   ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Talk-us] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

Frederik just answered Steve, but no message was received from Steve on the 
talk list. Bad documentation of the thread and difficulty to follow discussions 
coming from two lists, talk and talk-us. I then suggest that this thread be 
only on talk.

>From the list that Frederik provided earlier (ie. 
>http://www.remote.org/frederik/tmp/chdr.details),it is easy to extract the 
>id's for one region or country and query the Overpass-API as the example below 
>with a list of way's id.

way(id:102501108, 103339404, 103339466, ...);
out meta;>; out meta; 
 
Pierre 


  De : Frederik Ramm 
 À : Tod Fitch ; Steve Friedl  
Cc : Talk Openstreetmap ; talk...@openstreetmap.org
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

What do you think is  google source for names in Canada ;)
 
Pierre 


  De : Paul Norman 
 À : talk@openstreetmap.org 
 Envoyé le : Dimanche 27 août 2017 11h24
 Objet : Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr
   
On 8/27/2017 7:26 AM, john whelan wrote:
> I would suggest that any street names added by chdr in Canada were 
> more than likely derived from CANVEC sources

What makes you believe this to be so?

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


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

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

As James said earlier, canvec/geobase opendata provides the street names. This 
can be easily corrected. But we need to establish a procedure and identify 
which ways chdr originally added the name.
We can look simply at the history with a link to the OSM APIexample adding the 
id after way/ : 
http://www.openstreetmap.org/api/0.6/way/110941725/history
Looking at the list Frederik provided for Quebec, Canada for the first 10 
elements, I see that for 7 of 10, chdr simply modified the typo.
1. names originally added by chdr 
example: id=103339404, 103339466, 1205299902. chdr simply modified the typo
example id=102499927, 102501108, 104524659, 104524663, 110941725,  117091567, 
119245374

regard
 
Pierre 


  De : Frederik Ramm 
 À : Talk Openstreetmap ; "talk...@openstreetmap.org 
Openstreetmap"  
 Envoyé le : Dimanche 27 août 2017 9h51
 Objet : [OSM-talk] Redacting 75,000 street names contributed by user chdr
   
Hi,

  in 2010 I was privately contacted by another OSM user with the
suspicion that user "chdr" might be copying names from Google maps
(there were few "easter eggs" in Oman that were only on Google and not
in the real world, and they suddenly popped up on OSM). "chdr" was
contacted at the time, but continued unfazed. In 2013 another mapper
lodged a complaint with DWG about edits by chdr, and I emailed chdr
asking him about his sources. At that point chdr stopped mapping. He
never replied about his sources though, even when I set an ultimatum (of
31st August 2013) threatening to remove all names he contributed if he
can't tell us his source. We do have to assume that all names
contributed by chdr are copyright violations.

(chdr has added names all around the world, making a harmless survey
unlikely.)

For various reasons I neglected to act on this, and was only reminded
now, 5 years later, when DWG received a complaint from a user in Brazil
where chdr has even used "source=google" occasionally. (But as I said,
the suspicion is that Google was used throughout.)

I have now compiled a list of all street names that were contributed by
chdr and are still visible today; we're talking about almost 75,000
street names world wide. The most affected countries are:

  18023 "United States of America"
  16345 "Mexico"
  15109 "Brazil"
  6791 "RSA"
  2802 "Spain"
  2614 "Australia"
  1923 "Argentina"
  1673 "Nigeria"
  1569 "India"
  1441 "Canada"
    954 "Malaysia"
    744 "Botswana"
    717 "Philippines"
    619 "Indonesia"
    553 "Italy"
    414 "Turkey"
    290 "Hungary"
    284 "Chile"
    250 "Kenya"
    127 "Saudi Arabia"
    107 "Paraguay"
    106 "Panama"
    100 "Morocco"

I've left out those countries with less than 100 affected ways.

For the US, I can break it down by state:

  5696 "Arizona"
  5116 "Texas"
  2294 "New York"
  1164 "District of Columbia"
    740 "Iowa"
    494 "Colorado"
    416 "New Jersey"
    339 "Illinois"
    268 "Michigan"
    239 "Pennsylvania"
    181 "Missouri"
    147 "Georgia"
    129 "New Mexico"
    123 "North Carolina"
    115 "California"
    106 "Virginia"

The breakdown for Mexico:

  7749 "Baja California"
  2084 "Puebla"
  1964 "Chihuahua"
  1539 "Coahuila"
  1161 "Mexico"
  1040 "Chiapas"
    342 "Tamaulipas"
    241 "Sonora"
    185 "San Luis Potosi"
    129 "New Mexico"

and Brazil:

  10904 "São Paulo"
  2605 "Paraná"
    945 "Rio de Janeiro"
    270 "Rio Grande do Sul"
    154 "Goiás"

and South Africa:

  4422 "Gauteng"
    750 "KwaZulu-Natal"
    600 "Eastern Cape"
    439 "Western Cape"
    400 "Northern Cape"
    179 "Mpumalanga"

- each time leaving out a couple others under 100.

We believe that only names, not geometries have been taken from other
maps so we'll remove and redact the names only. In identifying "names
contributed by chdr" I took care to really only pick up the names that
were introduced by them, not names that were there before, and also when
chdr split a way that had a name I will make sure that the newly created
way doesn't count as "named by chdr". Additionally, I have ignored those
cases where chdr simply performed a TIGER expansion (St->Street etc) of
a name that was there before.

My process has two weak points (that I am aware of):

1. It doesn't properly "follow" a chrdr-contributed name through way
splits performed by other users; if someone has split a way created by
chdr, then the name will remain on the bit that was created by this
user. This is somewhat unsatisfying but after having manually checked a
random sample I think the problem is small enough to be ignored.

2. It is possible that, like with a recent case in Switzerland where I
had to do a similar redaction, some of these chdr-contributed names will
have been confirmed by others in a survey, i.e. someone else surveyed
the area and checked the name, but saw no need to change it in any way
since it was already correct. Sadly my process will now remove the name
even though, had the name not been there in the first place, that person
could have added the name. 

Re: [OSM-talk] "NRCS basic OSM training" - low quality changesets in Nepal

[Pierre Béland]

Hi Dan
I agree with you that we have to be careful to be cordial in the messages we 
write on notes. Yes, this is not easy for new contributors to respond to the 
notes, especially if they mainly contribute through smartphones. And 
contributors should be careful in the messages they add on notes.

But the organizers should assure the interaction with the OSM community and 
assure we can trace easily these edits for eventual corrections. if the edit 
comment always contain a hashtag or a word such as nrcs, it should be easy to 
trace the various edits.

Is Kathmandu Living Labs in the loop? They are quite experienced and could help 
on this. 
  
Pierre 


  De : Dan Joseph 
 À : talk@openstreetmap.org 
 Envoyé le : mercredi 21 juin 2017 17h51
 Objet : Re: [OSM-talk] "NRCS basic OSM training" - low quality changesets in 
Nepal
   
Hi,NRCS stands for Nepal Red Cross Society, so the people behind the edits are 
part of the local community. The mappers would be local volunteers and may not 
be comfortable responding to changeset comments that are written in English. I 
would also guess that changeset comments were not part of the training. Errant 
keys are relatively straight-forward to find and fix in JOSM. If the tag value 
is legitimate local knowledge then a little bit of cleanup work is worth it. 
Someone at the Nepal RC who does some GIS work is aware of the data quality 
issues and working to fix it. Training people who have access to smart-phones 
and computers and who regularly use map services can be a challenge. Training 
people who don’t have such access is even more of a challenge. The time before 
every edit is perfectly in line with the established OSM guidelines is bound to 
be a bit longer. Changeset comments such as "It's likely we have to fully 
delete it because it would take days to clean everything up by hand." when 
talking about local knowledge added by locals seems against the spirit of 
OSM.All the best,
Dan
On Wed, Jun 21, 2017 at 3:21 PM, Jan Michel  wrote:

Hi,
I wrote some changeset comments as well as Michałs. None of the was answered up 
to now, despite many new edits have been made by the users.

It's not just single mistakes, but they accumulate to a substantial amount of 
data, here's just a small excerpt of what I found:

Key     Occurences
addr:tole    127
Addr:city    19
addr: opening time    28
addr: place    24
Addr:place    35
godawari municipality    34

New keys are "invented" every day. I think something should be done soon as 
cleaning this up is quite some effort. I wonder if there is somebody from the 
local community available to help?

Jan



On 18.06.2017 23:42, Andrew Hain wrote:

Have you tried politely making changeset comments asking this?

--
Andrew
-- -- 
*From:* Michał Brzozowski 
*Sent:* 18 June 2017 21:32:16
*To:* talk@openstreetmap.org
*Subject:* [OSM-talk] "NRCS basic OSM training" - low quality changesets in 
Nepal
There has been a number of users making very low quality edits
(lowercase names, wrong tags. geometry problems among others) in
Nepal. They all use this mysterious changeset description: "NRCS basic
OSM training"
If this is training, then the instructor clearly has no OSM expertise required.
The mappers seem to make similar errors: misusing tags in addr:*
namespace, making up amenity=* tags, starting names from lower case.



Can we pin down who trains these mappers and demand them to stop and
take corrective action?

Michał



__ _
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.or g/listinfo/talk


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


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

Re: [OSM-talk] Looking for "primary language" map

[Pierre Béland]

Do you want to know the various languages spoken or only a simplified official 
language map? Your need is not very clear. 
 
Pierre 


  De : Yuri Astrakhan 
 À : James  
Cc : OpenStreetMap talk mailing list 
 Envoyé le : lundi 10 avril 2017 20h14
 Objet : Re: [OSM-talk] Looking for "primary language" map
   
James, thanks, but I was hoping for the language regions shapefile, e.g. in the 
GeoJSON form.  The list of official languages will require a lot of work to 
convert into the merged shapes, and it still not very good, as many countries 
have several official languages, e.g. Switzerland.
On Mon, Apr 10, 2017 at 7:55 PM James  wrote:

Also have you checked: 
https://en.wikipedia.org/wiki/List_of_official_languages_by_country_and_territory
On Apr 10, 2017 7:50 PM, "James"  wrote:

More like French for the entirety of the province of Quebec
On Apr 10, 2017 7:38 PM, "Yuri Astrakhan"  wrote:

Does anyone know of an open source language map - basically a set of geoshapes 
with the corresponding language code?  Country boundaries are not needed - e.g. 
Canada and USA would be English with the exception of French for Montreal area.
This is needed to guesstimate what language the "name" tag is in.
Does not have to be very precise (10-20 MB is more than enough)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk




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


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

Re: [OSM-talk] A tool for picking up settlements tagged as a single building?

[Pierre Béland]

Hi John,
The OSM Changeset Analyzer let's select bbox and option parameters including 
big building. To test if it provides too many positive answers. There could be 
an other option for very big buildings??

example with reason 34 Large buildings
http://osmcha.mapbox.com/?bbox=9.272%2C-13.496%2C43.901%2C6.315&is_suspect=False&is_whitelisted=True&checked=All&reasons=34


  
Pierre 


  De : john whelan 
 À : OpenStreetMap talk mailing list  
Cc : "h...@openstreetmap.org" 
 Envoyé le : samedi 25 mars 2017 13h28
 Objet : [OSM-talk] A tool for picking up settlements tagged as a single 
building?
   
It's something I've noticed in Africa so its probably not putting new mappers 
through a month's training first but many villages have been mapped but tagged 
as a single building with building=yes.

They aren't grouped together but rural Africa doesn't have that many large foot 
print buildings so it should be possible to pick them out based on location and 
size.

Any thoughts on how to pick them out?

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


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