Re: [Talk-ca] Building Import

[Pierre Béland via Talk-ca]

Bonjour Tim
Mon outil d'analyse Qualité dont les données sont publiées sur OpenDataLabRDC 
est basé sur PostgreSQL-Postgis.   Je suis à nettoyer / documenter le code et 
prévoit le publier sur github.  J'ai commencé à regarder les outils possibles, 
mais peu de documentation disponible. On parle par exemple de OpenCarto, mais 
l'info n'est plus disponible. A voir si possible à l'aide de Grass. 
https://gis.stackexchange.com/questions/15612/is-it-possible-to-simplify-orthogonal-polygons-with-opencarto-java-library
 
Pierre 
 

Le mardi 26 mars 2019 21 h 33 min 39 s HAE, Tim Elrick  a 
écrit :  
 
 I sent Daniel a sample of Montreal (Outrement) from the Open Building 
Database and Daniel's algorithm performed really well. It could reduce 
the vertices count by 13% without loosing or even improving data quality 
(as it orthogonalized the buildings). Even difficult buildings were 
treated well [1].

As OSM is mainly built on open source tools, the OSMF tries to work with 
open source tools only and the process should be reproducible (if not 
for this import, then for the next one somewhere else in the OSM 
cosmos), I suggest, we try to resemble Daniel's pre-processing in open 
source software, e.g. PostGreSQL/PostGIS. I already found the code for 
collinearity; the orthogonalization seems to be a bit trickier, but it 
should be possible to built the process in PostGIS as well, if it was 
possible to built it in FME. What do you think?

Tim

[1] https://imgur.com/a/aCKMVb7

On 2019-03-26 13:45, Jarek Piórkowski wrote:
On Tue, 26 Mar 2019 at 13:10, Begin Daniel  wrote:
> There is actually no standard “code” available since I use FME 
> (www.safe.com). It is a proprietary ETL application and all operations are 
> done using “transformers” (https://www.safe.com/transformers/). I can provide 
> you with the workbench I developed (a bunch of linked transformers) but you 
> need a license to run it. This is why I tried to describe the operations I 
> run on the data in the wiki.
> 
> As you did, people may send me coordinates (bounding box) of an area they 
> know well. I’ll process the area and send the results back in OSM format. 
> Please, be reasonable on the amount of data to process ;-)

Thanks Daniel. Let me know how it looks then!

Coming from an open-source background, the process is unusual to me,
and I have questions about scalability - will you be able to process
and provide updated data files for all of Canada then? - but if others
are comfortable with it then I won't object.

Some general thoughts regarding tooling as raised upthread:

I was initially excited to see building footprints data as they help
two quite distinct purposes:

1. they provide a mostly-automatic source of geometries for the
millions of single-family houses that wouldn't be mapped in the next
decade otherwise

2. they might provide a corrected and fairly accurate source of
geometries in heavily-built-up areas, where GPS signal is not that
reliable and it can be really difficult to get sufficiently accurate
geometries from imagery, whether because it's not sufficiently
high-resolution, two sets of imagery with conflicting offsets (Bing
and Esri are the two best sets in Toronto, and they're off by about
1-2 m on north-south axis from each other - that's not something I can
check with a consumer-grade GPS so I'm left guessing as to which is
true), or non-vertical imagery (I can count the floors on supposedly
top-down imagery in some cases).

  From what I saw, imports in the GTHA initially focused on the first
case, and I think the Tasking Manager setup was mostly sufficient for
those - where there is nothing currently on the map, or a few simple
2D geometries, a 4 sq km area can feasibly be done in under an hour.

However, as raised by others, I would really want the working squares
in Old Toronto for example to be no more than 500 m x 500 m, or no
more than 1 km x 1 km in St. Catharines. I would _love_ to have the
geometries to manually compare and adjust the 3D buildings already
existing in the area, but it will be much slower.

--Jarek

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



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

Re: [Talk-ca] FW: Building Import

[Pierre Béland via Talk-ca]

Voir https://github.com/opendatalabrdc/Documentation/tree/master/topology où 
nous avons entreposé des fichiers geojson du projet de OpenDatalabRDC pour 
consultation.voir par 
exemplehttps://github.com/opendatalabrdc/Documentation/blob/master/topology/topology-irregular-forms-OC_Kampala_hotosm_4360_2018_04_07.geojson
La création d'un répertoire similaire facilliterait la consultations par tous 
des données.  Lors de la consultatin, on clique sur un polygone pour consulter 
les variables d'analyse.
 
Pierre 



 

Le mardi 26 mars 2019 17 h 34 min 24 s HAE, Begin Daniel 
 a écrit :  
 
 Screenshots? A good idea for having everyone seeing the results over 
complicated polygons (I will try keep objective in my selection ;-)

I am working to get it right on multiple adjacent polygons. I'll make the 
results available after I got them.

Daniel

-Original Message-
From: Jarek Piórkowski [mailto:ja...@piorkowski.ca] 
Sent: Tuesday, March 26, 2019 17:19
To: Begin Daniel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] FW: Building Import

Hi Daniel,

If you are interested, some more potentially complicated areas around
Golden Horseshoe for testing. Each is roughly one screen on z16. I
don't know some of these as much, you might want to post results as
data files or screenshots for others to also look at to increase
buy-in.

- Spadina Chinatown and Kensington Market in Toronto, small buildings
tight in against each other, many semi-detached or attached, and some
larger ex-industrial buildings: 43.6569,-79.3868,43.6477,-79.4086
- University of Waterloo, with smaller attached residence buildings
that might have somewhat complicated shapes, as well as large
interconnected school buildings: 43.4740,-80.5362,43.4648,-80.5580
- downtown Kitchener, using a variety of grid alignments and some
buildings that might not be square: 43.4562,-80.4782,43.4470,-80.5000
- downtown Hamilton also has streets that aren't at right angles:
43.2619,-79.8572,43.2527,-79.8790
- St. Catharines might also be not square: 43.1640,-79.2322,43.1547,-79.2540
- Unionville, older area of Markham: 43.8717,-79.2993,43.8625,-79.3211

You will notice a trend of downtowns with non-square grids. I'm sure
others will be happy to contribute more examples of areas with
geometries they'd consider tricky. Bigger buildings might be more
likely to not be square if they're built out to max out the available
lot. I imagine only-slightly-non-square grids will be most
challenging...

--Jarek

On Tue, 26 Mar 2019 at 16:49, Begin Daniel  wrote:
>
> As usual, missed the reply all …
>
>
>
> From: jfd...@hotmail.com
> Sent: Tuesday, March 26, 2019 16:26
> To: 'John Whelan'
> Subject: RE: [Talk-ca] Building Import
>
>
>
> It is really kind to consider my background ;-)
>
> You are right regarding the "black box" approach; this is why a large 
> approval from the community is required before I go further.
>
>
>
> Daniel
>
>
>
> From: John Whelan [mailto:jwhelan0...@gmail.com]
> Sent: Tuesday, March 26, 2019 16:04
> To: Begin Daniel
> Cc: Jarek Piórkowski; talk-ca@openstreetmap.org; keith hartley; Alessandro 
> (STATCAN)
> Subject: Re: [Talk-ca] Building Import
>
>
>
> I think my concerns are to do with the "black box" approach.  Knowing your 
> background I trust your work but others might not.
>
> On a technical side I get the impression that cites with buildings that are 
> close to each other are problematical.  I assume that small locations with a 
> population of say under 125,000 this is an insignificant problem?
>
> The other issue is I'd like to either see buy in from Nate or at least some 
> Toronto mappers to get an indication that something will happen at the end of 
> the day as it is a fair chunk of Daniel's time to work out how do the 
> preprocessing.
>
> I think some BC mappers expressed some doubts as well so perhaps they would 
> like to think about if they are happy or would prefer BC to be outside of the 
> import project and express their views.
>
> Out of interest if it does move ahead are we including the Microsoft data for 
> areas where we do not have data from Stats Canada?  If so we will need to 
> amend the project plan.
>
> My personal view is realistically I think having building information even if 
> its a meter or two out is better than not having the building outlines.
>
> What would be nice is if we could have some indication from places such as 
> Manitoba, Alberta, Saskatchewan, Quebec excluding Montreal, Ontario excluding 
> Toronto and the other provinces and territories whether they are happy with 
> importing the buildings either from Stats or Microsoft.
>
> I seem to recall Keith is in Manitoba, so any views other than it wasn't 
> present in the first release from Stats?
>
> Note to Alessandro this is just background stuff.
>
> Thanks
>
> Cheerio John
>
> Begin Daniel wrote on 2019-03-26 3:29 PM:
>
> Jarek,
>
> The area you proposed in quite interesting and will force me to look further 
> at buildings with sharing 

Re: [Talk-ca] Building Import

[Pierre Béland via Talk-ca]

Voici les observations que j'ai fait à Daniel a partir des données du premier 
test qu'il a effectué pour Toronto.

Un premier examen visuel pour le BBOX utilisé montre que l'outil a produit 
correctement les formes orthogonales en général. J'ai constaté cependant des 
cas où un des angles n'aurait pas du être corrigé.   exemple 
https://www.openstreetmap.org/way/285346662
En milieu urbain dense, je constate aussi de nombreux chevauchements de 
polygones avec des bâtiment très prés ou  qui préalablement partagaient un 
vertice commun. Le traitement d'un bloc d'immeuble pourrait être une solution 
pour éviter les chevauchements. Cependant, si on retrouve des angles non 
rectangulaires avec plus de 10 degrés d'écart, il faudrait conserver ces angles 
tels quels.Exemple, batiment 540, qui fait angle non rectangulaires sur un coin 
de rue. https://www.openstreetmap.org/way/661895522
 
Pierre 
 

Le mardi 26 mars 2019 15 h 30 min 13 s HAE, Begin Daniel 
 a écrit :  
 
 Jarek, 
The area you proposed in quite interesting and will force me to look further at 
buildings with sharing edges, a concern Pierre also had. I'll be back soon with 
your area processed.
Daniel  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[Pierre Béland via Talk-ca]

John, 

les contributeurs de Ottawa, vous semblez en général d'accord pour poursuivre 
les imports et avez la capacité technique de faire des imports rapides, ce que 
vous avez démontré.  Il ne manque qu'un petit pas à franchir et discuter de la 
qualité des données et accepter de tenir compte des communautés en général.
Essaies tu de dire que les 6 contributeurs qui ont fait des imports se sont 
limités à des territoires locaux, voire leur province et ont discuté avec les 
communautés locales sur la méthodologie satisfaisante pour corriger les données 
avant l'import ?   Pour le Québec, je peux te dire que non.

Je constate plutot un refus de discuter et une volonté de poursuivre malgré les 
opinions divergentes. Et la qualité ?  J'ai clairement démontré il me semble 
que les tracés imprécis étaient clairement visibles.  Et si je comprends bien, 
nous avons maintenant un million de nouveaux bâtiments que l'on pourrait 
«blanchir» si n'importe qui met un tampon approuv dessus.  Je dois dire que 
l'argument est difficile à avaler.
 
Pierre 
 

Le vendredi 15 mars 2019 14 h 02 min 23 s HAE, John Whelan 
 a écrit :  
 
 Which I think comes back to defining the local mappers.

There has been discussion on Montreal as well and not all Ontario thinks the 
same way.  Ottawa local mappers for example have different opinions to Pierre 
and Nate on what is acceptable and I'm under the impression that not everyone 
in Toronto agrees with Nate's position.

We seem to be blocking out parts of the country such as Montreal is this a 
reasonable approach?

Can we find someway to loosely define local groups and their areas of 
responsibility and how to contact them?

For example one small Ontario city has to my knowledge one OpenStreetMap mapper 
who maps very occasionally.  My understanding is they would be quite happy to 
see an import happen but many of the buildings have already been mapped 
although not to the accuracy that the Stats Can data offers.  How do you deal 
with these smaller cities and townships?

Thanks

Cheerio John  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building import in BC and Quebec

[Pierre Béland via Talk-ca]

Réponse immédiate avec refus de discussion de la part de DannyMcD_imports. 
Celui-ci indique qu'il prévoit continuer l'import.voir 
https://www.openstreetmap.org/changeset/67686901
| 
There was a discussion, issues were raised, the problems (to the extent that 
they existed at all) have been addressed. I plan to continue importing, unless 
a *specific* valid issue is raised. Please do not contact me again unless you 
have such an issue.
 |


La prochaine étape est je pense de contacter le Data Working Group.
 
Pierre 
 

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

Re: [Talk-ca] Building import in BC and Quebec

[Pierre Béland via Talk-ca]

Bonjour Jarek
Ce n'est malheureusement pas le seul contributeur qui agit ainsi.  J'estime en 
divisant (Objets/5) que depuis le 1er février, 6 contributeurs ont importé près 
de 1 million de bâtiments. Selon les commentaires, 5 provinces ont été 
couvertes. Cette information est parfois inexacte. Un fichier json des bbox de 
chaque changeset nous fournirait une information plus précise.Voir par exemple 
https://www.openstreetmap.org/changeset/67725913 
J'ai joint ci-dessous un tableau sommaire et la liste des changesets par 
contributeur.

Nous faisons face à un import massif. Ce ne sont pas des débutants qui font ces 
imports et ces contributeurs doivent justifier leurs actions depuis le début 
février et expliquer la méthode suivie pour corriger les données. 
Je viens juste d'aviser chacun de ces contributeurs de cesser les imports et 
venir en discuter sur la liste.
https://www.openstreetmap.org/changeset/67725913
https://www.openstreetmap.org/changeset/68043362
https://www.openstreetmap.org/changeset/68112880
https://www.openstreetmap.org/changeset/67956418
https://www.openstreetmap.org/changeset/67686901
https://www.openstreetmap.org/changeset/68131003

    Imports Statcan depuis le 1er février - Nombre d'objets par 
province

| 
 | OSM Uiid | 
 | 
 | 
 | 
 | 
 | 
 |
| Province | 215433 | 1919010 | 5214232 | 5323321 | 9266764 | 9444677 | Total |
| Alberta | 152 033 | 
 | 
 | 474 276 | 
 | 586 403 | 1 212 712 |
| BC | 44 115 | 
 | 
 | 1 833 617 | 
 | 506 552 | 2 384 284 |
| New Brunswick | 389 750 | 
 | 
 | 
 | 
 | 
 | 389 750 |
| Ontario | 
 | 2 758 | 
 | 
 | 470 608 | 
 | 473 366 |
| Québec | 297 444 | 
 | 110 484 | 753 | 
 | 
 | 408 681 |
| Total | 883 342 | 2 758 | 110 484 | 2 308 646 | 470 608 | 1 092 955 | 4 868 
793 |


Liste des changesets par contributeurUid 215433 Alberta 67665215, 67665288, 
67665341, 67665453, 67665483, 67665545, 67665602, 67665808, 67665875, 67666001, 
67666180, 67669204, 67669252, 67669308, 67669354, 67669452, 67669522, 67669613, 
67670220, 67670247, 67670273, 67670311, 67670349, 67670387, 67670421, 67670458, 
67670536, 67670908, 67670939BC 67508204, 67508256, 67508291, 67508458, 
67508490, 67508513, 67508622, 67508649, 67508697New Brunswick 67507944, 
67508112, 67508134, 67530245, 67530288, 67530337, 67530387, 67530430, 67530474, 
67530523, 67530791, 67530835, 67531044, 67531220, 67531330, 67531597, 67531938, 
67532009, 67532116, 67532730, 67532743, 67569125, 67569223, 67569803, 67569881, 
67569899, 67569919, 67569960, 67602916, 67603189, 67603261, 67603269, 67603307, 
67603335, 67603367, 67603432, 67603554, 67603678, 67603804, 67604023, 67604270, 
67604320, 6779, 67700103, 67700186, 67700343, 67701266, 67701566, 67704840, 
67704865, 67704907, 67705047, 67705069, 67705120, 67705156, 67705204, 67705284, 
67705553, 67705562, 67705602, 67705662, 67705703, 67705762, 67705815, 67705920, 
67705931, 67706273, 67706329, 67706346, 67706464, 67706503, 67706521, 67719310, 
67719682, 67720148, 67720387, 67720605, 67720722, 67720888, 67720980, 67721152, 
67721270, 67723337, 67724221, 67724317, 67724413, 67724441, 67724618, 67724667, 
67724722, 67724746, 67724785, 67724876, 67724959, 67725077, 67725194, 67725830, 
67725849, 67725878, 67725913, 67725961, 67787993Québec 67498534, 67498609, 
67498689, 67498757, 67498912, 67505394, 67505479, 67505545, 67505558, 67505578, 
67505614, 67505972, 67506005, 67506059, 67506089, 67506346, 67506485, 67506686, 
67506719, 67506875, 67506907, 67506934, 67506947, 67506976, 67507006, 67507027, 
67507041, 67507049, 67507068, 67507105, 67507117, 67507136, 67507160, 67507175, 
67507185, 67507195, 67507202, 67507216, 67507260, 67507285, 67507297, 67507312, 
67507320, 67507331, 67507344, 67507355, 67507356, 67507363, 67520439, 67520589, 
67521376, 67521445, 67521517, 67522086, 67522182, 67523774, 67523861, 67523987, 
67524091, 67524121, 67524132, 67524260, 67524661, 67524728, 67524805, 67525070, 
67525203, 67525335, 67525528, 67526340, 67526436, 67526514, 67526916, 67527123, 
67527293, 67527489, 67527970, 67528040, 67528316, 67528511, 67528581, 67528645, 
67528686, 67528728, 67528787, 67528860, 67528901, 67528967, 67529024, 67529042, 
67529077, 67529173, 67529225, 67529262, 67529307, 67529347, 67529374, 67529413
Uid 1919010 Ontario 68042707, 68042895, 68043362, 68043390, 68043779, 68043921, 
68044088
Uid 5214232 Québec 67957273, 67957348, 67957729, 67958923, 67959011, 67986700, 
67986777, 68069537, 68069649, 68078450, 68078523, 68112014, 68112112, 
68112880Uid 5323321 Alberta 66858409, 66858508, 66858697, 66931104, 66931208, 
66931808, 66932459, 66937105, 66944951, 66945388, 66945814, 66945894, 66946017, 
66946173, 66946358, 66960875, 66961117, 66961283, 66961447, 66962026, 66962184, 
66963495, 66963589, 67022393, 67033345, 67033434, 67033507, 67037604, 67037672, 
67037926, 67038133, 67046475, 67046558, 67046687, 67047191, 67047267, 67047343, 
67047419, 67048115, 67048188, 67048931, 67048997, 67049058, 67049627, 67050230, 
67050277, 

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

Re: [Talk-ca] Some feedback on import quality in Toronto

[Pierre Béland via Talk-ca]

Danny
Voici un exemple à partir des données d'Ottawa pour tester la fonction de 
correction du Validateur. La requête Overpass ci-dessous permet d'extraire des 
bâtiments jumelés pour les résidences Brookds sur le campus de l'Université 
d'Ottawa.http://overpass-turbo.eu/s/FPT
La correction individuelle de chaque bâtiment à l'aide de la fonction Réparer 
du Validateur JOSM ne corrige que les angles externes et laisse telles quelles 
les nodes partagées avec d'autres bâtiments.   Après correction de tous les 
bâtiments, on constate que les bâtiments ne sont pas orthogonaux là où nodes 
partagées. Et relance lors de la du Validateur, cela n'est pas détecté.
Dans un tel cas, je pense qu'il est mieux de sélectionner un bloc de plusieurs 
bâtiments jumelés et d'utiliser la touche de raccourci «Q» pour orthogonaliser 
l'ensemble. Seul problème, avec le premier bloc de trois bâtiments du haut où 
le bâtiment du centre, le 100 Thomas Moore, a une forme arrondi dans le bas qui 
doit être retracée après l'orthogonalisation. 

Il y a aussi des situations où il semble aussi nécessaire de réviser la forme 
des bâtiments. Voir, par exemple, le 342 Wilbrod street.  La fonction Réparer 
du Validateur JOSM ne donne pas de bons résultats. Après orthogonalisation de 
l'ensemble des trois bâtiments à l'aide de la touche «Q», il est ensuite 
possible selon l'interprétation de l'imagerie de réviser le bâtiment du centre 
à l'aide par exemple de la touche «X».
 
Pierre 
 

Le lundi 4 février 2019 10 h 32 min 17 s HNE, Danny McDonald 
 a écrit :  
 
 In JOSM, open the preferences dialog (F12), go to the data validator tab, and 
click the "show informational level" checkbox (it is third from the top).  Any 
validation done will then check for "Building with an almost square angle", 
which will appear under the Other tab.  "Building with an almost square angle" 
used to cause a Warning, but it was downgraded to Other due to complaints - see 
https://josm.openstreetmap.de/ticket/16280.Danny
On Mon, Feb 4, 2019 at 9:45 AM Yaro Shkvorets  wrote:

Danny,Do you mind sharing how to fix almost square angles in JOSM? I remember 
seeing such warning a year or two ago but for some reason I don't see it 
anymore and can't find it in the Validator settings. Did they remove it from 
the latest version of JOSM or you need to add this rule manually?If there is an 
easy way to do it then we should do it I guess.

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

Re: [Talk-ca] Some feedback on import quality in Toronto

[Pierre Béland via Talk-ca]

J'ai constaté la même chose a tester CATools. Décevant.

Et merci à Dany, cette fonctionnalité est intéressante.La requête Overpass 
ci-dessous extrait de grands immeubles à Ottawa, certains avec des formes 
rectangulaires, d'autres avec des formes plus complexes, moitié rectangulaire, 
plus divers angles.http://overpass-turbo.eu/s/FNY

Ce qui manque pour corriger de telles géométrie, c'est un outil qui permettrait 
de redresser partiellement, de mettre en parallèle certains cotes, ou redresser 
un angle à 90 degrés, voire 60, 45 a un certain point.  

Pour les demi-cercles, on sélectionne  3 points et outil / Arc de cercle.
 
Pierre 
 

Le lundi 4 février 2019 10 h 50 min 02 s HNE, Yaro Shkvorets 
 a écrit :  
 
 Thanks, it works. Need to run it a few times it looks like. On a random 
Markham block went from 88 warnings down to 4 without ruining geometries, which 
is acceptable IMO. May need to look into its parameters 
(validator.RightAngleBuilding.maximumDelta and 
validator.RightAngleBuilding.minimumDelta) to tweak it for our data.
I've looked into CADTools and BuildingGeneralization plugins but unfortunately 
they don't work properly destroying geometries and rotating polygons.
-- 
Best Regards,
          Yaro Shkvorets  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Some feedback on import quality in Toronto

[Pierre Béland via Talk-ca]

En faisant une recherche josm + orthogonal, je trouve ce greffon qui semble 
intéressanthttps://wiki.openstreetmap.org/wiki/JOSM/Plugins/CADTools Il 
contient différentes fonctions pour corriger les polygones. Je vois que l'on 
utilise une tolérance 85-95 pour les angles droits. Il est aussi possible de 
modifier les paramètres.


Pierre 
 

Le lundi 4 février 2019 09 h 46 min 17 s HNE, Yaro Shkvorets 
 a écrit :  
 
 Danny,Do you mind sharing how to fix almost square angles in JOSM? I remember 
seeing such warning a year or two ago but for some reason I don't see it 
anymore and can't find it in the Validator settings. Did they remove it from 
the latest version of JOSM or you need to add this rule manually?If there is an 
easy way to do it then we should do it I guess.
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Je suggère oui, d'abord le script avec 2 fichiers d'output parce qu'ensuite il 
sera beaucoup plus simple d'importer les données déja corrigées. Sinon une 
variable pour distinguer les deux et risque de l'importer dans OSM ? Et je 
pense à un autre aspect. Le script pourrait s'assurer qu'il n'y a pas de 
superpositions entre bâtiments une fois les données corrigées.

L'importation des données orthogonales devrait être grandement facilitée. Selon 
l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère une fois 
les polygones qasi-orthogonaux corrigés. Pour ces données, il s'agirait 
davantage de valider avec l'imagerie et de faire la conflation avec les données 
existantes. 

Pour l'importation des données irrégulières, il faudrait oui valider / 
corriger. A ne pas oublier que dans ce cas on retrouve des angles qui 
s'éloignent de plus de 5 degrés vs données orthogonal. C'est visuellement 
facile à repérer.  Souvent, il s'agirait simplement avec JOSM d'utiliser la 
touche «Q» pour orthogonaliser.  De nombreux appendices de batiments on un 
angle prononcé dans le fichier et cela peut etre redressé à 90 degrés. Le 
greffon ToDo est très utilie pour réviser successivement des données et 
s'assurer de toutes les réviser.

A titre d'exemple, on peut décider d'orthogonaliser le bâtiment ci-dessous avec 
beaucoup d'angles se rapprochant de 90 degrés mais avec une variance plus 
grande que +-5 degrés. Pour détecter davantage de bâiments quasi-orthogonaux, 
il serait possible de tenir compte de cette situation uniquement pour angles à 
90 avec critère tolérance +-10 degrés. Je vais tester cette option et voir si 
cela permettrait de détecter un grand nombre de cas.angles entre 82.6 et 94.5 
degrés
{82.6,85.7,87.4,90.3,96,94.5,85.5,84.8,91,90.8,89.3,89.8,90.4,91.1,91.1,93.6,87.1,82,87.3,84.7}
https://www.openstreetmap.org/way/479048070
Pierre 
 

Le dimanche 3 février 2019 15 h 45 min 33 s HNE, john whelan 
 a écrit :  
 
 I accept the nicest way is to check the data beforehand.  Scripting it is 
fairly simple.  Are you suggesting a two stage process of take the data and run 
the script first then task manager the data to be imported to manually correct 
the data?  My eyesight isn't good enough to pick out none right angled corners 
so is there some way someone can come up with to feed them into a JOSM todo 
list?

However we have a fairly large number of building outlines that have already 
been imported.  The issue here is different as extra tags have been added.  Can 
the questionable ones be identified in such a way that a JOSM todo list can be 
used to correct them rather than throw out all the work that has been done 
adding tags?
I think you are assuming a more top down management arrangement than exists 
with volunteer Canadian mappers.

Thanks John
  


  

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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

John
Oui, je suggère  à ceux qui préparent un plan d'importation, de modifier la 
donnée avant l'importation. Des critères comme ceux que j'ai présenté 
pourraient être utilisés dans un script pour simplifier les polygones qui sont 
quasi orthogonaux. 

Pour simplifier la procédue d'import, deux fichiers distincts pourraient être 
produits :
1. Formes géométriques quasi-orthogonales corrigées - import plus rapide - mais 
a voir si problèmes lorsque des bâtiments voisins partagent des nodes.
2. Formes géométriques irrégulières - Import avec révision / correction plus 
serrée. 

Il reste à ceux qui mènent le projet de faire ces développements logiciels. Et 
pourquoi pas, de proposer des outils que les communautés locales pourront 
ensuite utiliser. Par contre éviter qu'un petit groupe importe rapidement les 
données et ignore le rôle des communautés locales. 

Et l'argument, si tu t'opposes, tu est responsable pour ta communauté, nous ont 
fait le reste du pays, à mon avis cela ne tient pas la route.
 
Pierre 
 

Le dimanche 3 février 2019 14 h 57 min 45 s HNE, john whelan 
 a écrit :  
 
 So you're proposing that a script is run to correct minor deviations in the 
remaining data which sounds a reasonable approach to me and would improve data 
quality.
So run the data through the script.  Then import and run overpass to pick out 
those that need manual adjustment?
If we do this though then I think we need to stay with the single import plan 
rather than have individual import plans popping up that didn't use the scripts.
I have no control over the number of mappers importing or the rate at which 
they import and I'm not sure how you would mange this other than having a 
person identified in the wiki as leading a particular area and there is 
provision or rather was I'm not sure what the latest version says.
Even with smaller import plans there would be nothing to stop one mapper 
bringing in building outlines very quickly.
Cheerio John


 


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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

De tes exemples sortis du chapeau ne font pas avancer la discussion. 

J'attends la démonstration de John que les données d'import pour Ottawa 
représentent bien le contour des bâtiments et sont des données de qualité.
 
Pierre 
 

Le dimanche 3 février 2019 12 h 07 min 55 s HNE, john whelan 
 a écrit :  
 
 From OSMweekly 445 and I'm not sure if it is relevant or not.
Cheerio John


Imports
   
   - Frederik Ramm suggested reverting a four-year-old building import in 
Ulster County, New York State, because only simple squares had been imported 
instead of the correct building outlines. Two years ago the import was featured 
by Worst of OSM.

On Sat, 2 Feb 2019 at 10:57, Nate Wessel  wrote:

  
If they weren't hand traced, how were they made? I don't believe I've actually 
seen any documentation on this. Do we know how these buildings footprints were 
made? Just because we didn't trace them from imagery ourselves doesn't mean 
someone working for a city GIS department didn't do exactly the same thing some 
time ago. 
 
 
We're concerned with squaring because buildings generally have right angles. If 
the data don't have right angles too, then like you said it likely indicates 
poor quality data. 
 
 
Best,
 
 Nate Wessel
 Jack of all trades, Master of Geography, PhD candidate in Urban Planning
 NateWessel.com 
 
  On 2/2/19 10:48 AM, Danny McDonald wrote:
  
 On squaring buildings, no one has yet been explained why buildings should be 
square.  My understanding is that non-square buildings are a warning sign for 
mapathons with hand-traced buildings - the lack of squaring is often noticeable 
for hand-traced buildings, and indicative of generally poor building 
footprints. That doesn't apply here, since the buildings involved are not 
hand-traced (at least in Toronto).  In fact, the imported footprints are 
generally extremely accurate, much better than would (or could) be done by 
hand. 
  It seems like the automated verification tool (of checking whether buildings 
are square or not) is being misapplied in this case. 
  DannyMcD  
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

 Le «acid test» de John, avec une architecture aussi irrégulière, a abimé les 
«Bay Windows» et l'eau fuit de partout tout comme son analyse basée sur Orléans 
à l'extérieur de la zone étudiée ! Une analyse plus approfondie de la zone du 
centre-ville nous montre qu'il y a peu de telles architectures. Cette réponse 
ne tient pas la route et n'explique pas le ratio élevé de polygones avec formes 
irrégulières dans la base OSM.

Le feedback de Nate pour Toronto montre qu'il a a beaucoup de données à 
corriger pour orthognaliser. voir 
https://lists.openstreetmap.org/pipermail/talk-ca/2019-February/009080.html

Ce que je comprends bien aux réactions de John depuis le début, c'est laissons 
les données telles qu'elles.  Plusieurs évitent de se pronconcer. Cela ne me 
convainct pas de l'urgence pour un petit groupe de se hâter à importer les 
données sans tenir compte de problèmes de qualité importants.

J'ai révisé mon script qualité pour cerner davantage les formes régulières. Il 
tenait compte jusqu'ici des angles à 90 degrés et des autres formes régulières 
(hexagones, octogones, etc). Je l'ai révisé au cours des derniers jours 
acceptant une tolérance jusqu'à 5 degrés. Les angles à 45 degrés  (ie. 45, 135, 
225, 315) sont maintenant pris en compte. 

Ces modifications ont eu peu d'impact sur le nombre de bâtiments identifiés 
avec formes irrégulières. Cela confirme qu'il a a des polygones avec formes qui 
s'éloignent sensiblement de formes régulières.

Avec une tolérance de 3 à 5 degrés, on constate que 17% des bâtiments peuvent 
être orthogonalisés automatiquement à l’aide de scripts. Ou encore il serait 
possible de réviser tous les bâtiments avec tolérance de 1 à 5 degrés (ceux à 
moins de 1 degrés resteraient tels quels. Malgré tout, Il reste toujours 25% 
des bâtiments qui doivent être analysés manuellement et voir si des corrections 
sont nécessaires.

 Pierre 
 

Le jeudi 31 janvier 2019 20 h 48 min 03 s HNE, john whelan 
 a écrit :  
 
 I can't think of a way to pull in all the suspect buildings but if you have a 
look here:
https://www.openstreetmap.org/search?query=k4a%201m7%20canada#map=19/45.47095/-75.48696

556, 558, 560 are all examples that I think would fail your test.  However they 
are the shape of the buildings.
As far as I am aware we haven't had any outraged users complaining about the 
building shapes in Ottawa and that I think is the acid test.  The Ottawa 
building import has been useful certainly in gaining new mappers and adding 
tags to the outlines.
Your test originally was to pick out very badly mapped buildings that had been 
done in iD and I would agree with you that some were very bad.  Sometimes 3 or 
4 times the size of the building and some very odd shapes indeed.  From memory 
most were done on HOT tasks with the iD editor.
These I think we should definitely aim to avoid but where the representation of 
the building is reasonably accurate then I think they are acceptable.  We are 
using reasonably experienced mappers who would balk at importing some of the 
stuff we saw in Nepal etc and rightly so.  They'd almost certainly be very 
vocal about the quality of the data.
There is a case to be made that most residential buildings would be acceptable 
if they were mapped with the JOSM buildings_tool plugin and all the small blobs 
take up database size.  There is also a case that you get a better sense of the 
building with the small blobs, bay windows etc.  I don't have strong feelings 
either way but I strongly suspect there are examples of both already in OSM in 
Canada.
I note that both Google and Bing have most buildings these days and it has 
almost become a map user expectation.  Certainly there are apps that guide 
blind people that use the building outlines in OSM.  There is a case that says 
to keep up with the competitors we really ought to have buildings.
I think someone else has commented that parts of the Microsoft building outline 
from scanned images in the US is problematic.
So given the results in Ottawa are comparable to Ontario and in my opinion 
Ottawa is acceptable then I think the rest is also acceptable.  Certainly 
Kingston where not all building angles were right angles weren't noticeable to 
me by eye or perhaps my eyesight is just getting worse with age.
Cheerio John


On Thu, 31 Jan 2019 at 19:51, Pierre Béland  wrote:

Salut John,
Voici les résultats d'analyse de géométrie des bâtiments pour Ottawa 
centre-ville.bbox : 45.4224,-75.6994,45.4568,-75.6122
-  20,372 Bâtiments
-      173 Bâtiments avec superposition  (0.1%)
-   11,534 Bâtiments avec formes irrégulières  (56.6%)

Nous avons donc un résultat semblable aux imports en Ontario que j'ai analysé 
il y quelques jours. A mon avis, en haut de 5%, il faut regarder de plus près 
et expliquer pourquoi autant de formes irrégulières.

J'ai créé des Requêtes overpass pour extraire les bâtiments identifiés dans 
l'analyse. Télécharger les requêtes à partir des fichiers ci-joints. 

Pierre 
 

173

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Salut John,
Voici les résultats d'analyse de géométrie des bâtiments pour Ottawa 
centre-ville.bbox : 45.4224,-75.6994,45.4568,-75.6122
-  20,372 Bâtiments
-      173 Bâtiments avec superposition  (0.1%)
-   11,534 Bâtiments avec formes irrégulières  (56.6%)

Nous avons donc un résultat semblable aux imports en Ontario que j'ai analysé 
il y quelques jours. A mon avis, en haut de 5%, il faut regarder de plus près 
et expliquer pourquoi autant de formes irrégulières.

J'ai créé des Requêtes overpass pour extraire les bâtiments identifiés dans 
l'analyse. Télécharger les requêtes à partir des fichiers ci-joints. 

Pierre 
 

173 Batiments avec superposition
Req Overpass 
voirhttps://www.dropbox.com/s/fp1cimouhhfbm9s/on_Ottawa_centre_2019-01-31_batiments_superposes_OSM_req_Overpass.txt?dl=0

11,534 Bâtiments avec formes irrégulières  (56.6%)
Req Overpass voir 
https://www.dropbox.com/s/c68nb9dbudtp679/on_Ottawa_centre_2019-01-31_batiments_irreg_OSM_req_Overpass.txt?dl=0





-

Le lundi 28 janvier 2019 09 h 17 min 37 s HNE, john whelan 
 a écrit :  
 
 Interesting, although I'm not sure what the best approach is.  
31 Hamilton is interesting.  If you look at the buildings next to it they don't 
have house numbers.  Look at the history and you'll see it was first created in 
2010 with potlatch and edited once more in 2011.
At my first glance at Kingston the small deviations form 90 degrees did not 
stand out. 
I think we can reasonably expect Microsoft to create a Canadian buildings file 
and you seem to be comfortable that the ones it has in the US are of a 
reasonable standard.
Part of my background is large databases and my personal view is the minimum 
data needed the faster the system runs and less data needs to get flipped round 
and backed up.
Could you run the analysis over Ottawa?
Looking closely at a few in Ottawa I note that there are some bay windows and 
other small features I might not have bothered with if mapping with JOSM with 
the buildings_tool. Because of a few 45 degree angles involved this isn't 
something that can be easily solved.
Ottawa I think at some level can be considered a reasonable success.  Certainly 
we added a lot of extra information to the building outlines.
I think the trade off is using the municipal data gives us the buildings with 
perhaps more detail than I might like but many would like to see the buildings 
imported.
Dunno (Do not know for translate tools.)
What is the ideal building outline in OpenStreetMap?
What is an acceptable building outline in OpenStreetMap?  

Suggestions
Thanks
Cheerio John

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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Ok John,
je vais lancer le script pour Ottawa. Mais je dois régler petit soucis 
d'instabilité  windows avec java et osmosis.  Ne peut mettre a jour java. Et 
powershell refuse parfois de reconnaitre commandes exe.

Parmi tous les scripts de conversion de raster / vectoriel, il serait oui 
intéressant de trouver un script opensource qui corrige les problèmes 
d'orthogonalisation. 

Un défi supplémentaire, lorsque des batiments adjacents partagent des lignes de 
contour. Dans JOSM, lorsque je vois de telles situations, je traite si possible 
en bloc tous les batiments et réoriente ensuite si nécessaire pour mieux 
correspondre à l'imagerie.

 
Pierre 
 

Le lundi 28 janvier 2019 09 h 17 min 37 s HNE, john whelan 
 a écrit :  
 
 Interesting, although I'm not sure what the best approach is.  
31 Hamilton is interesting.  If you look at the buildings next to it they don't 
have house numbers.  Look at the history and you'll see it was first created in 
2010 with potlatch and edited once more in 2011.
At my first glance at Kingston the small deviations form 90 degrees did not 
stand out. 
I think we can reasonably expect Microsoft to create a Canadian buildings file 
and you seem to be comfortable that the ones it has in the US are of a 
reasonable standard.
Part of my background is large databases and my personal view is the minimum 
data needed the faster the system runs and less data needs to get flipped round 
and backed up.
Could you run the analysis over Ottawa?
Looking closely at a few in Ottawa I note that there are some bay windows and 
other small features I might not have bothered with if mapping with JOSM with 
the buildings_tool. Because of a few 45 degree angles involved this isn't 
something that can be easily solved.
Ottawa I think at some level can be considered a reasonable success.  Certainly 
we added a lot of extra information to the building outlines.
I think the trade off is using the municipal data gives us the buildings with 
perhaps more detail than I might like but many would like to see the buildings 
imported.
Dunno (Do not know for translate tools.)
What is the ideal building outline in OpenStreetMap?
What is an acceptable building outline in OpenStreetMap?  

Suggestions
Thanks
Cheerio John
On Sun, 27 Jan 2019 at 23:28, Pierre Béland  wrote:

Bonjour John
La géométrie des bâtiments est un sujet qui préoccupe plusieurs contributeurs 
en particulier pour les imports de données. Dans un tel cas, il est difficile 
de revenir en arrière et il est préférable de bien planifier, analyser.  Comme 
on le voit avec l'import en Ontario, on observe qu'il est possible de s'assurer 
que les données soient orthogonales et que les noeuds inutiles soient éliminées.
En comparaision les données  Microsoft importées à Arlington, au Texas 
présentent des géométries plus standard.  À première vue, les ratios de 
géométrie irrégulières semblent beaucoup plus bas. 

Une nouvelle analyse pour l'Ontario, cette fois-ci pour les données importées 
dans la zone Oshawa-Hamilton montre 62% sont des polygones avec des formes 
irrégulières.
A noter que pour déterminer les polygones réguliers, j'utilise un spectre de 
degrés assez large 
- lignes droites entre 178 et 182 degrés
- angles droits entre 88 et 92 degrés, entre 268 et 272
- autres types de polygones : variation de +-2.2% vs angle moyen pour le 
polygone (octogones, hexagones, etc)
Dans les analyses de géométrie, un grand nombre de polygones classés FB_oo ont 
des géométries où on retrouve des batiments presque orthogonaux mais avec un ou 
des angles entre 86 et 94 degrés. Cela veut sans doute représenter des angles 
droits mais l'écart est assez grand. Dois-t-on se satisfaire de cela? 
En ce qui a trait aux normes de qualité, elle sont généralement implicites et 
guidées par les outils disponiibles. Avec JOSM, on s'attend généralement qu'un 
contributeur utilisera le greffon Building et saura tracer des batiments 
rectangulaires et si nécessaire superposer plusieurs formes rectangulaires 
légérement décalées et les joindre en un seul polygone.  Les contributeurs 
devraient normalement aussi maitriser les notions de perspective lorsque 
l'image est prise avec un certain angle par rapport à la verticale.  Les outils 
d'intelligence artificielle aussi ?

Selon toi, quelles règles devrait-on appliquer pour évaluer la géométrie des 
bâtiments ?
L'exemple de géométrie que tu as présenté, on le retrouve effectivement 
beaucoup dans les imports pour l'Ontario. Ce bâtiment n'est pas dans mon 
fichier par ce que le contributeur n'était pas répertorié dans le projet 
http://tasks.osmcanada.ca/project/145. Je n'ai retenu que les contributeurs qui 
y apparaissait.
Pour des exemples similaires contenus dans le fichier d'analyse, regardes près 
du 31 Hamilton 
street.https://www.openstreetmap.org/#map=20/44.23749975223997/-76.49539748034509
  
Ce polygone contient 22 angles, des quasi lignes droites (symbole ir), et des 
quasi 90 degrés (oo) et des angles

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Bonjour John
La géométrie des bâtiments est un sujet qui préoccupe plusieurs contributeurs 
en particulier pour les imports de données. Dans un tel cas, il est difficile 
de revenir en arrière et il est préférable de bien planifier, analyser.  Comme 
on le voit avec l'import en Ontario, on observe qu'il est possible de s'assurer 
que les données soient orthogonales et que les noeuds inutiles soient éliminées.
En comparaision les données  Microsoft importées à Arlington, au Texas 
présentent des géométries plus standard.  À première vue, les ratios de 
géométrie irrégulières semblent beaucoup plus bas. 

Une nouvelle analyse pour l'Ontario, cette fois-ci pour les données importées 
dans la zone Oshawa-Hamilton montre 62% sont des polygones avec des formes 
irrégulières.
A noter que pour déterminer les polygones réguliers, j'utilise un spectre de 
degrés assez large 
- lignes droites entre 178 et 182 degrés
- angles droits entre 88 et 92 degrés, entre 268 et 272
- autres types de polygones : variation de +-2.2% vs angle moyen pour le 
polygone (octogones, hexagones, etc)
Dans les analyses de géométrie, un grand nombre de polygones classés FB_oo ont 
des géométries où on retrouve des batiments presque orthogonaux mais avec un ou 
des angles entre 86 et 94 degrés. Cela veut sans doute représenter des angles 
droits mais l'écart est assez grand. Dois-t-on se satisfaire de cela? 
En ce qui a trait aux normes de qualité, elle sont généralement implicites et 
guidées par les outils disponiibles. Avec JOSM, on s'attend généralement qu'un 
contributeur utilisera le greffon Building et saura tracer des batiments 
rectangulaires et si nécessaire superposer plusieurs formes rectangulaires 
légérement décalées et les joindre en un seul polygone.  Les contributeurs 
devraient normalement aussi maitriser les notions de perspective lorsque 
l'image est prise avec un certain angle par rapport à la verticale.  Les outils 
d'intelligence artificielle aussi ?

Selon toi, quelles règles devrait-on appliquer pour évaluer la géométrie des 
bâtiments ?
L'exemple de géométrie que tu as présenté, on le retrouve effectivement 
beaucoup dans les imports pour l'Ontario. Ce bâtiment n'est pas dans mon 
fichier par ce que le contributeur n'était pas répertorié dans le projet 
http://tasks.osmcanada.ca/project/145. Je n'ai retenu que les contributeurs qui 
y apparaissait.
Pour des exemples similaires contenus dans le fichier d'analyse, regardes près 
du 31 Hamilton 
street.https://www.openstreetmap.org/#map=20/44.23749975223997/-76.49539748034509
  
Ce polygone contient 22 angles, des quasi lignes droites (symbole ir), et des 
quasi 90 degrés (oo) et des angles irréguliers tles 98,8, 94,3
Est-ce un polygone irrégulier ou un effet de perspective? Comment le 
représenter?
"59879471"    "22"    "FB_irreg"    
"{o,o,o,o,ir,ir,ir,ir,oo,o,o,oo,oo,ir,oo,o,oo,rr,ir,ir,o,o}"    
"{90.6,90.7,89.3,89.2,95.4,94.8,178,83.2,86.1,90.9,89.2,94,93.6,94.3,93.1,89.9,93.8,171.2,98.8,94.3,90.9,89.9}"

Angle 177,6 presque droit, noeud inutile - normalement un simple rectangle
"657790097"    "5"    "FB_irreg"    "{o,o,ir,o,o}"    "{90,91,177.6,91.4,90}" 
Un peu d'humour la-dessus. Un robot trace un rectangle parfait. Un premier 
contributeur le voit et dit cela ne semble pas normal et y ajoute un peu de 
distorsion. Un deuxième décide d'y ajouter un point et d'étirer le tout. Si on 
poursuit le dessin dans ce sens, cela finira par ressembler à un clown!


Pierre 
 

Le dimanche 27 janvier 2019 09 h 51 min 10 s HNE, john whelan 
 a écrit :  
 
 If you take a look at 942 Bridle Path Crescent for example whilst it isn't 
exactly square the deviations from 90 degrees to me are relatively minor.  I 
assume that this is the sort of thing you are talking about?

https://www.openstreetmap.org/search?query=942%20Bridle%20Path%20Crescent%20kingston#map=19/44.25311/-76.59308
Are we expecting too high a standard?
Cheerio John

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

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Nate je viens juste de publier les résultats pour Kingston. Un ratio de 66% de 
polygones avec formes irrégulières. A voir si la simplification éliminerait les 
noeuds qui ont pour effet de créer des formes irrégulières. 

Je n'ai pas encore regardé de près les résultats. Cependant, m on expérience en 
République démocratique du Congo depuis l'an dernier, Kisenso et récemment 
Butembo, a montré qu'a partir de ces diagostics, la validation / correction si 
nécessaire des polygones permettait de réduire fortement les ratios, et ce sous 
les 3% des bâtiments.
Je pense aussi qu'il faut prendre le temps de corriger les données qui risque 
de ne pas être modifiées par la suite. 


 
Pierre 
 

Le samedi 26 janvier 2019 21 h 06 min 39 s HNE, Nate Wessel 
 a écrit :  
 
  
James, 
 
 
It does seem that someone will need to properly simplify the data since you 
don't seem willing to do the necessary work. I've already offered to help, but 
I can't do it today, or tomorrow for that matter. My suggestion, again, is that 
we slow down and take the time to do this right. Rushing ahead can only lead to 
hurt feelings, angry emails, and extra work for everyone. Given how much 
editing goes on in the areas I know, many of these imported buildings might not 
be touched again for another decade - can't we make them right the first time?
 
 
I think Pierre is on the right track here with his thoughtful analysis of the 
buildings that have been imported so far - this is the kind of stuff that I'm 
talking about when I say we need some validation. Some questions that I'd like 
to see answered (Pierre, when you have some more time!): just how many 
buildings imported so far are not orthogonal, but seem like they should be? 
What percentage of buildings would benefit from simplification, and is the 
problem worse/better in some areas compared to others?
 
I actually don't think the problem is technically difficult to solve - we just 
have to understand the nature and extent off the problem before we rush to 
solutions. That's the point of validation - understanding what the problems are.
 
 
Best,
 
 Nate Wessel
 Jack of all trades, Master of Geography, PhD candidate in Urban Planning
 NateWessel.com 
 
 
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[Pierre Béland via Talk-ca]

Voici mon analyse de la géométrie des bâtiments pour Kingston.  À partir des 
uid des contributeurs ayant participé à l'import, j'ai téléchargé pour Kingston 
5,261 batîments créés ou modifiés par eux depuis le 24 décembre. Le fichier 
résultat montre 5,253 batiments, quelques polygones en erreur éliminés.
Requête Overpass http://overpass-turbo.eu/s/FzI 
Fichier OSM et Résultats d'analyse  
https://www.dropbox.com/s/1dn76c7gmk996ql/on_kingston.import_2018_12_24.osm.zip?dl=0
L'analyse de la géométrie des bâtiments ci-haut révèle que 66% d'entre eux  
(3,475 / 5,261) ont des formes irrégulières.  Ce ratio de géométries 
irrégulières est très élevé, bien au delà de ce à quoi on devrait normalement 
s'attendre. 


méthodologie
À noter que l'analyse qualité avec JOSM permet de détecter de nombreux 
problèmes, incluant les doublons, superpositions.  Mais aucune analyse de la 
géométrie n'est effectuée.  

Mais il est possible malgré tout de d'analyser les géométries et développer des 
indicateurs qui permettent de lever un Drapeau Regarder de plus près au-dela 
d'un certain niveau. J'identifie les formes régulières comme ci-dessous et 
accepte une tolérance de 2.2% plus ou moins avant de signaler comme forme 
irrégulière.

Polygones avec formes régulières
- forme avec angles droits (90 degrés, 270 degrés)- forme avec angles constants 
(hexagone, octogone, etc)

C'est un domaine où on ne peut mesurer à partir d'une simple formule les 
géométries valides même si avec des formes irrégulières.Par contre, tout ratio 
supérieur à 5 % mérite à mon avis d'être analysé de plus près pour expliquer 
les écarts.

Mon script qualité tient compte de tous les noeuds sauf angle=180 degrés pour 
évaluation géométrie.  Vous pourrez comparer dans le fichier analyse les 
diagnostics individuels pour chaque polygone et pour chacun les angles 
correspondants.

ci-dessous, voici des exemples de résultas de l'analyse des 3,475 bâtiments 
avec formes irrégulières. 

 id nb_angles    forme   type angle angles

"56709982"    "5"    "FB_irreg"    "{o,ir,ir,o,o}"    
"{90,174.9,94.6,90.1,90.3}"
id ci-haut a un 5ième angle presque a 180 degrés. faire zoom-in pour voir.

"56997713"    "14"    "FB_oo"    "{oo,oo,o,o,o,o,o,o,o,o,o,o,o,o}"    
"{92.8,92.2,89.9,90.3,89.9,90.4,90,89.7,89.5,89.5,89.3,88.9,89.2,90.1}"id 
ci-haut, 14 angles, très pres de 90 degrés, mais imprécis
À noter que le script est en développement. Si vous trouvez des incohérences, 
me le signaler.
o et r :     formes régulièresFB_oo et FB_rr : formes presque 
régulièresFB_irreg    formes irrégulières

Pierre 

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

Re: [Talk-ca] Talk-ca Digest, Vol 131, Issue 46

[Pierre Béland via Talk-ca]

Bonjour James
Je réponds rapidement et reviendrai plus tard avec une analyse quantitative 
pour Kingston où j'observe visuellement beaucoup de formes irrégulières. Pour 
une analyse argumentée, il faut régler les petits soucis. Mon ordinateur plante 
lors de lecture du gros fichier geojson dans QGIS ou JOSM et je n'ai pas de 
script pour le fractionner en fichiers plus petits. J'ai donc fait des extraits 
osm des données importées récemment.

J'analyse donc les données à partir de OSM pour voir les formes irrégulières et 
celles qui pourraient être corrigées.  J'ai fait quelques extraits dans 
différentes villes d'Ontario mais n'ai pas eu le temps de calculer la 
proportion de formes irrégulières.

Pour ce qui est des angles, je ne parles pas ici de que quelques décimales que 
seuls les ordinateurs peuvent déceler !

On doit évidemment ignorer les bâtiments dont les images révèlent une 
architecture de formes irrégulières.  L'analyse consiste davantage à identifier 
les bâtiments mal tracés, dont les angles sont presque droits mais tracés avec 
des angles différents.

L'imagerie Esri haute résolution i a un certain offset vs Bing mais permet de 
zoomer davantage et mieux comparer les formes. Ðans cette zone à Kingston, je 
vois plusieurs bâtiments presque a angle droit. Il est facile dans un tel cas 
de corriger a 90 degrés. 
https://www.openstreetmap.org/#map=21/44.2369514/-76.4905765
Formes régulières dont les angles presque droits devraient être 
corrigésexemplesway(id: 657792023, 657792735, 55652473, 657791586, 61429073, 
657793764); out meta; >; out meta;

Pour angles a 180 degrés, il est possible d'enlever les noeuds à condition que 
non partagés avec bâtiment adjacent. Par contre, ce n'est sans doute pas facile 
à programmer.

Je vois aussi des cas où un bâtiment apparait rectangulaire mais près d'un 
angle un point avec un angle prononcé semble inutile et crée une forme 
irrégulière. Parfois c'est une question d'interprétation lorsque en particulier 
des images ne sont pas prises à la verticale. Un toit, comme ici sur image 
DigitalGlobe Premium laisse croire qu'il y a un angle. Par contre bien tracé 
dans OSM.
http://openstreetmap.org/way/657793764
Et l'architecture d'une ville à l'autre, d'une époque à l'autre crée des formes 
aux géométries très différentes. Cependant mon analyse au cours des derniers 
mois de la géométrie des bâtimemts me fait dire que si le ratio ( batiments 
irréguliers (non orthogonal) / Total bâtiments) est plus grande que 5%, c'est 
un signal qu'il faut analyser les données de près et expliquer pourquoi tant de 
bâtiments ont des formes irrégulières. 

Exemples où je vois des corrections possibles 
way(id: 657794001, 55652494, 657790090, 657794217); out meta; >; out meta;


 
Pierre 
 

Le samedi 26 janvier 2019 10 h 01 min 25 s HNE, James  
a écrit :  
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  i haven't simplified because, no one gave me feedback on the data...Not going 
to process a bunch of datafiles for someone to turn around and say the 
simplification broke something.
On Sat., Jan. 26, 2019, 9:57 a.m. Danny McDonald https://lists.openstreetmap.org/listinfo/talk-ca

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

[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: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[Pierre Béland via Talk-ca]

Mon problème est dés le téléchargement. Cela m'indique que google ne peut 
effectuer l'analyse d'antivirus et m'offre de télécharger quand même. De là, 
message d'erreur.Voici le message avec Chrome
Ce site ne peut pas fournir de connexion sécurisée

doc-08-3g-docs.googleusercontent.com a envoyé une réponse incorrecte.
   
   - Essayez d'exécuter les diagnostics réseau de Windows.
ERR_SSL_PROTOCOL_ERROR
 
Pierre 
 

Le samedi 19 janvier 2019 23 h 10 min 04 s HNE, James  
a écrit :  
 
 tar.xz c'est un fichier compressé contenant un fichier geojson(il se ouvre 
bien avec 7zip sur windows, ou n'importe quel program d'archive sur mac ou 
Linux), qui est servie via la Task Manager. Ce n'est pas la version originale 
de Stats Can, tu as raison, c'sst la version minifié sans les extras tag de 
merde qui sont aucunement utile à OSM.
Je travaille sur les fichiers, car quelqu'un a dit les données était de la 
bouse de vache.
On Sat., Jan. 19, 2019, 11:02 p.m. Pierre Béland  a 
écrit : 

Is there no one that will analyse the data I've posted here? 
https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
 or are we just email thread warriors?


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

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[Pierre Béland via Talk-ca]

James,

Je pense que nous travaillons sur deux aspects différents. Tu te concentre sur 
la production / correction des fichiers d'import.
A ma connaissance, tu n'a pas décrit le contenu dufichier 
ontario-simplified.tar.xz.  Je suppose que ce sont les données d'import 
originales où tu apportes divers correctifs.
De mon côté, je propose d'analyser le produit final dans la base OSM et mesurer 
pour les données déja téléchargées quelle proportion des bâtiments est avec 
angles droits (orthogonal), et les superspositions.  Cela permettrait 
simplement de comparer ces données avec ce que l'on retrouve ailleurs et 
rassurer sur la qualité globale de l'import par les différents contributeurs. 

Normalement, on ne devrait pas retrouver plus de 5% des bâtiments avec formes 
irrégulières,  sinon il faut regarder de plus près et expliquer pourquoi.  Mes 
analyses au cours des derniers 6 mois, incluant révision de Butembo en RDC 
montrent qu'avec une bonne révision on repère beaucoup de bâtiments qui ne 
correspondent pas à ce que l'on observe sur l'imagerie.

Je n'ai pas réussi à télécharger le fichier  ontario-simplified.tar.xz à partir 
de Google drive,  ni avec Chrome, ni avec Firefox ni à l'aide d'un script wget. 
Je ne sais si windows 10 peut ajouter des restrictions que d'autres OS n'ont 
pas.

Pierre 


Le samedi 19 janvier 2019 17 h 01 min 22 s HNE, James  a 
écrit : 

Is there no one that will analyse the data I've posted here? 
https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
 or are we just email thread warriors?

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

Re: [Talk-ca] OpenStreetMap, education and the buildings

[Pierre Béland via Talk-ca]

Effectivement James,
Comme ailleurs en Europe, les communautés OSM sont beaucoup plus organisées.
La communauté OSM-France a mis en place des serveurs qui permettent l'accès à 
la carte OSM. On y retrouve aussi Osmose, uMap et l'hébergement du style 
humanitaire.  Au SOTM-Fr à chaque année,  quelque 100 personnes de tous 
horizons convergent pour y participer. Aussi, beaucoup de projets, notamment 
avec les organisations locales et autres. Et depuis longtemps, ils organisent 
localement des journées OSM avec écoles, municipalités et autres intervenants.

Ils ont donc la capacité de gérer de tels projets, de se coordonner avec les 
établissement scolaires. Ce sera intéressant de voir ce qui sera réalisé dans 
le monde scolaire.
 
Pierre 
 

Le samedi 19 janvier 2019 20 h 47 min 15 s HNE, James  
a écrit :  
 
 That's french: France. Not french: Québec
On Sat., Jan. 19, 2019, 8:44 p.m. John Whelan From weeklyosm:


Education
   
   - The new curriculum (pdf) for French high schools states that all students 
should be introduced to geospatial data usage. One of the expected abilities in 
that domain is the ability to “contribute to OpenStreetMap in a collaborative 
way”.
-- 

What it means is we can expect to see more interest from schools in Canada.  
Adding tags to buildings is fairly simple and less error prone than some 
activities. 

Using streetcomplete I think would work even without buildings.

Thoughts please.

Thanks John





Sent from Postbox___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[Pierre Béland via Talk-ca]

Voici une compilation statistique à partir des changesets de OSM pour la grande 
région de Toronto (bbox=-80.8951,42.9142,-78.1046,44.3297).  Depuis 
Pour respecter la politique de confidentialité de OSM, les contributeurs ne 
sont identifiés que selon leur uid.
Depuis décembre, on compte 6 contributeurs, 889 changesets et 6,621,124 objets 
édités (noeuds, chemins ou relations) 
1 immeuble = 5 objets minimumLe fichier de changeset ne fournit que le nombre 
d'objets édités (var num_changes). On ne peut donc à cette étape-ci que 
grossièrement estimer le nombre d'immeubles, sans doute plus de 1 million déjà. 
A partir de Overpass, on ne peut facilement extraire les données. Je vais 
télécharger dans PostGIS un fichier récent de l'Ontario et sélectionner les 
données éditées depuis le 24 décembre (premier jour avec édition )  de ces 6 
contributeurs.  Mon script Qualité permettra également d'analyser la géométrie 
des bâtiments.
lexique
changeset         nombre de changesets (sessions d'édition)num_changes    
nombre d'objets édités dans la sessionavg_changes     moyenne, objets édités 
par changeset
Tableau 1 - Objets édités par contributeur avec moyenne par changeset

| uid | changesets | num_changes | avg_changes | % cum |
| 9266764 | 457 | 3,439,242 | 7,526 | 52.7% |
| 215433 | 197 | 1,619,540 | 8,221 | 77.6% |
| 5214232 | 151 | 815,541 | 5,401 | 90.1% |
| 9343732 | 78 | 628,032 | 8,052 | 99.7% |
| 3016192 | 3 | 17,710 | 5,903 | 100.0% |
| 1919010 | 3 | 1,059 | 353 | 100.0% |
| 
 | 889 | 6,521,124 | 7,335 | 
 |



Tableau 2 - Objets édités par contributeur - jour avec moyenne par changeset

| uid | jour | changesets | num_changes | avg_changes |
| 5214232 | 2018-12-28 | 3 | 10,324 | 3,441 |
| 5214232 | 2019-01-14 | 11 | 58,402 | 5,309 |
| 5214232 | 2019-01-17 | 9 | 57,738 | 6,415 |
| 9343732 | 2019-01-16 | 7 | 63,490 | 9,070 |
| 215433 | 2018-12-29 | 8 | 70,562 | 8,820 |
| 5214232 | 2019-01-16 | 25 | 176,942 | 7,078 |
| 5214232 | 2018-12-23 | 5 | 29,279 | 5,856 |
| 9343732 | 2019-01-14 | 5 | 39,000 | 7,800 |
| 5214232 | 2019-01-12 | 10 | 48,329 | 4,833 |
| 5214232 | 2018-12-24 | 9 | 54,888 | 6,099 |
| 215433 | 2019-01-08 | 13 | 77,332 | 5,949 |
| 9266764 | 2019-01-08 | 20 | 156,232 | 7,812 |
| 9266764 | 2019-01-01 | 9 | 67,167 | 7,463 |
| 9266764 | 2019-01-07 | 19 | 154,837 | 8,149 |
| 215433 | 2019-01-02 | 30 | 280,756 | 9,359 |
| 9266764 | 2018-12-24 | 11 | 66,162 | 6,015 |
| 5214232 | 2019-01-11 | 2 | 6,219 | 3,110 |
| 9343732 | 2019-01-15 | 10 | 75,020 | 7,502 |
| 9343732 | 2019-01-11 | 11 | 82,844 | 7,531 |
| 215433 | 2018-12-30 | 20 | 177,602 | 8,880 |
| 9266764 | 2018-12-31 | 30 | 195,300 | 6,510 |
| 9343732 | 2019-01-12 | 14 | 111,821 | 7,987 |
| 215433 | 2019-01-03 | 25 | 200,002 | 8,000 |
| 9266764 | 2019-01-10 | 33 | 260,886 | 7,906 |
| 215433 | 2019-01-09 | 17 | 138,489 | 8,146 |
| 215433 | 2018-12-31 | 21 | 169,903 | 8,091 |
| 5214232 | 2019-01-09 | 9 | 41,664 | 4,629 |
| 9266764 | 2019-01-13 | 32 | 266,247 | 8,320 |
| 9266764 | 2018-12-29 | 36 | 274,357 | 7,621 |
| 9343732 | 2019-01-10 | 14 | 112,606 | 8,043 |
| 1919010 | 2019-01-17 | 2 | 973 | 487 |
| 9266764 | 2018-12-26 | 29 | 216,701 | 7,472 |
| 215433 | 2019-01-07 | 12 | 93,825 | 7,819 |
| 5214232 | 2019-01-10 | 2 | 718 | 359 |
| 9266764 | 2019-01-09 | 25 | 216,885 | 8,675 |
| 5214232 | 2019-01-08 | 27 | 119,761 | 4,436 |
| 5214232 | 2018-12-25 | 2 | 10,528 | 5,264 |
| 9266764 | 2019-01-06 | 18 | 142,007 | 7,889 |
| 215433 | 2019-01-01 | 6 | 58,083 | 9,681 |
| 9266764 | 2019-01-04 | 7 | 39,155 | 5,594 |
| 1919010 | 2019-01-16 | 1 | 86 | 86 |
| 9266764 | 2019-01-11 | 22 | 174,419 | 7,928 |
| 9266764 | 2018-12-25 | 29 | 188,931 | 6,515 |
| 9266764 | 2018-12-27 | 10 | 67,593 | 6,759 |
| 3016192 | 2018-12-20 | 3 | 17,710 | 5,903 |
| 215433 | 2019-01-04 | 15 | 128,047 | 8,536 |
| 9266764 | 2018-12-30 | 14 | 108,068 | 7,719 |
| 9266764 | 2019-01-15 | 21 | 150,419 | 7,163 |
| 5214232 | 2019-01-15 | 19 | 116,812 | 6,148 |
| 9266764 | 2019-01-14 | 17 | 135,021 | 7,942 |
| 9343732 | 2019-01-13 | 17 | 143,251 | 8,427 |
| 9266764 | 2019-01-12 | 16 | 120,488 | 7,531 |
| 215433 | 2019-01-06 | 13 | 103,233 | 7,941 |
| 5214232 | 2019-01-13 | 11 | 57,670 | 5,243 |
| 5214232 | 2019-01-07 | 4 | 7,256 | 1,814 |
| 215433 | 2019-01-05 | 13 | 99,108 | 7,624 |
| 9266764 | 2019-01-05 | 4 | 25,286 | 6,322 |
| 9266764 | 2019-01-16 | 24 | 204,397 | 8,517 |
| 215433 | 2019-01-17 | 2 | 18,589 | 9,295 |
| 215433 | 2018-12-27 | 2 | 4,009 | 2,005 |
| 9266764 | 2019-01-02 | 13 | 71,064 | 5,466 |
| 9266764 | 2019-01-03 | 18 | 137,620 | 7,646 |
| 5214232 | 2018-12-27 | 3 | 19,011 | 6,337 |
| 
 | 
 | 889 | 6,521,124 | 7,335 |



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

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

[Pierre Béland]

John,
Il y a local et local. Compte-tenu des différences culturelles Québec vs Canada 
en général et que les contributeurs du Québec ne fréquentent pratiquement pas 
cette liste, vous ne devriez pas prendre pour acquis que vous représentez cette 
communauté et pouvez démarrer des projets en son nom.
 
Pierre 
 

Le vendredi 18 janvier 2019 13 h 11 min 37 s HNE, john whelan 
 a écrit :  
 
 I know of no other way to contact him but he made an interesting comment that 
the project is on hold in the wiki pending review.
Would he care to comment on who is supposed to be reviewing the project?
My understanding is that the import was raised in talk-ca before it commenced 
for comment and these were generally favourable.  I took that as the local 
mappers to Canada had been consulted and they are the "local mappers" authority 
in this case.
I understand he has concerns about local mappers making decisions but in Canada 
we have been importing similar data through CANVEC for some time.  CANVEC data 
comes from a number of sources including municipal data.
Is he suggesting that each of the 3,700 municipalities in Canada should form a 
group of local mappers who can make individual decisions on whether their 
municipal data should be imported and we should end up with 3,700 import plans?
Thanks John

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

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: [Talk-ca] Import des arrêts d'autobus de l'ARTM

[Pierre Béland]

Bonjour Claude, 

je penses oui que c'est bon maintenant. C'est une procédure déja documentée 
pour l'import de ces itinéraires. Hâte de voir le résultat.
 
Pierre 
 

Le samedi 1 décembre 2018 14 h 58 min 00 s HNE, Alouette955 
 a écrit :  
 
 Merci Pierre, J’ai suivi tes conseils et écrit à la liste 
impo...@openstreetmaps.org:    
https://lists.openstreetmap.org/pipermail/imports/2018-November/005836.html il 
y a deux semaines et j’ai inscrit mon projet sur la page Imports/Catalogue du 
wiki. De plus un lien sur la page du wiki pointe vers une traduction en anglais 
de la page qui explique l’import. N’ayant pas reçu de commentaires au sujet de 
mon projet je me propose d’y aller avec l’import pour les réseaux dont j’ai 
obtenu l’autorisation. Une dernière chance de réagir ... Merci, Claude From: 
Pierre Béland Sent: Wednesday, November 14, 2018 5:26 PMTo: talk-ca ; 
Alouette955 Subject: Re: [Talk-ca] Import des arrêts d'autobus de l'ARTM 
Bonjour Claude, Il faut malheureusement être patients avec les imports. A 
noter, selon la procédure de la Fondation OSM, cette consultation, n'est que la 
première étape. Avant d'importer, il faut écrire sur la liste 
imp...@openstreetmap.org. De là, attend une semaine pour donner le temps de 
réagir.
 Indiques que suite à consultation de la communauté sur talk-ca et obtention 
d'autorisation, tu présentes le projet sur import@osm (voir page wiki contenant 
liens vers autorisations, certaines à venir).

Mentionnes le but de l'import et que méthode est décrite sur la page wiki. 
L'import sera fait par quelques contributeurs seulement qui connaissent le 
schéma de données pour les transports.

Pierre 
  Le mercredi 14 novembre 2018 16 h 48 min 48 s HNE, Alouette955 
 a écrit :   Bonjour, J’ai récemment soumis ici une 
proposition d’import des arrêts d’autobus de l’ARTM pour discussion en 
attendant l’autorisation des opérateurs de réseaux de l’ARTM. Je viens de 
recevoir l’autorisation du Réseau de Transport Métropolitain (exo) et j’ai mis 
à jour la page proposant l’import:    
https://wiki.openstreetmap.org/wiki/FR:Import_arr%C3%AAts_d%27autobus,_ARTM_Autorit%C3%A9_r%C3%A9gionale_de_transport_m%C3%A9tropolitain
 Ayant reçu des commentaires sur ma méthode et l’ayant adaptée en conséquence 
je vais la mettre en oeuvre à moins d’un dernier commentaire de votre part. 
Merci, Claude___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


|  | Virus-free. www.avg.com  |

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

Re: [Talk-ca] BC2020 and School Mappers

[Pierre Béland]

http://jakobmiksch.eu/post/openstreetmap_overview/



 
Pierre 
 

Le samedi 24 novembre 2018 10 h 24 min 06 s HNE, John Whelan 
 a écrit :  
 
 http://teachosm.org/en/

Might be of some use.

Cheerio John

Jonathan Brown wrote on 2018-11-22 7:45 PM:



Alessandro had some engineering profs from the University of Rome working with 
a local high school for testing the mobile app used for BC2020. 

  

Here’s a Comenius program for Life Long Learning of the European Union EU. The 
official title of the project is: "To boost local and international tourism 
with OpenStreetMap". The project's acronym is: "BoostOSM" 
https://wiki.openstreetmap.org/wiki/Life_Long_Learning_Mapping_Project 

  

Jonathan

  

From: John Whelan
Sent: Thursday, November 22, 2018 7:08 PM
To: Jonathan Brown
Cc: Talk-CA OpenStreetMap
Subject: Re: BC2020 and School Mappers

  

I hadn't thought about the programming side but C# certainly can be useful.

https://www.jatws.org/openstreetmap/openstreetmap.html

It needs visual studio 2017 but it has a sample program from which other 
programs looking for other things could be written.

I think that would be high school level though.

There has been some work in creating activities for schools in OSM but they 
would need chasing down.

Cheerio John

Jonathan Brown wrote on 2018-11-22 6:33 PM:




Climate change planning would be good. That topic could be linked to the UN 
sustainable development goals. Also, in Ontario there is a big need to 
incorporate math skills into learning by doing (e.g., 
http://www.barbareeduke.com/ccmath/mathactivities.htm (adapted for OSM), or for 
postsecondary GIS and programming for computer science courses.

At CivicTech Toronto Meetup last Tuesday someone pointed out David MacKay’s 
book Sustainable Energy: Without Hot Air https://withouthotair.com/ 

Jonathan 

 

 

From: john whelan
Sent: Thursday, November 22, 2018 5:46 PM
To: Jonathan Brown
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] BC2020 and School Mappers

 

So what do we need?

 

A hook of some type to build on?

 

An inventory of buildings for climate change planning?  I understand in many 
cities some 80% of apartment buildings are forty years old now and identifying 
them and upgrading them would help with climate change emissions.  
Unfortunately they tend to be privately owned and coaxing landlords to invest 
money is not easy.

 

An introduction to basic stats?

 

I'm not a teacher but I'm sure we can sort something out.

 

We do have a tasking manager that covers Canada so tiles can be set up for a 
local area.

 



I suggest an import first then something after that.

 

Thoughts

 

Thanks John

 

On Thu, 22 Nov 2018, 5:22 pm Jonathan Brown https://lists.openstreetmap.org/listinfo/talk-ca

 


  

-- 

Sent from Postbox

  

-- 
Sent from Postbox___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020 and School Mappers

[Pierre Béland]

Peut-être commencer par proposer aux écoles, universités etc. des informations 
leur permettant de s'initier à la cartographie numérique actuelle. Éditer, cela 
est très pointu comme initiation et la très grande majorité quittent après 
quelques heures laissant des données de mauvaise qualité
De fait, ne s'intéressent-ils pas d'abord à ce fameux Web 2.0, OpenSource, 
OpenData avec internet, ordinateurs, téléphones et tabletes, et les nouveaux 
modes sociaux de collaboration?  Il y a aussi les outils d'analyse tel QGIS, 
les outils de requête, toutes les thématiques préssentes sur OSM. Ce domaine 
évolue rapidement et les contributeurs OSM et développeurs collaborent avec 
gouvernements, organismes internationaux etc.
Il est aussi possible d'initier avec des journées thématiques où on visite un 
quartier ou village pour mieux le documenter. De telles journées sont aussi 
l'occasion d'initier par des discussions au monde de la cartographie numérique. 
 

Les projets cartographiques devraient venir ensuite et être mieux planifiés, en 
proposant du matériel et démarche pour un minimum de formation avant de 
cartographier.  Beaucoup de contributeurs OSM sont réticents aux opérations 
marketing de HOT où on invite tous et chacun à venir tracer sur la carte.  De 
grands chiffres de conribution. Mais quelle qualité ?
Les organisateurs de mapathons ne devraient pas avoir des connaissances 
limitées d'OSM. Ils devraient aussi avoir un plan de formation. Le risque comme 
on l'a vu trop souvent est que de nouveaux contributeurs s'initient à OSM en 
démarrant immédiatement la cartographie sans aucune connaissance et quittent 
après quelques heures, laissant souvent un nombre élevé d'erreurs. Avez-vous vu 
l'Analyse Qualité de la géométrie que j'ai produite à partir de 25 projets 
cartographiques HOT  ? 
Habituellement dans une municipalité, on ne retrouve qu'un faible pourcentage, 
nettement moins de 10% d'immeubles avec formes irrégulières (angles autres que 
90°). Beaucoup de projets avaient des taux supérieurs à 10%.
https://lists.openstreetmap.org/pipermail/talk/2018-September/081392.html 


Pierre 



 

Le jeudi 22 novembre 2018 17 h 21 min 27 s HNE, Jonathan Brown 
 a écrit :  
 
 
“Should we try to tailor the information on Building 2020 towards inexperienced 
mappers to make it easier for schools etc to get involved?”

  

Good idea, John. We need a process similar to HOT for local beginners and maybe 
a way of connecting the mapping to a sustainable development challenge in the 
community.

  

Jonathan 

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

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: [Talk-ca] Tagging paths that are snowploughed?

[Pierre Béland]

Il y a plusierus facettes à considérer ici, soit accès hivernal, état du 
sentier et services accessibles. 

La clé winter_service=yes indiquerait simplement que le sentier est disponible 
l'hiver et ne permettrait pas d'indiquer que le sentier est nettoyé facilitant 
l'accès aux velos.
Voici un usage différent mais qui nous éclaire sur les clés utiliisées pour 
décrire un service hivernal.
La Tuktoyaktuk Winter Road (chemin 50426104) est un autre type de service 
hivernal (Service abandonné l'hiver dernier suite à l'ouverture d'une nouvelle 
route).
Dans ce deuxième cas, cette tant le service que la piste n'existent que l'hiver.
Les clés OSM utilisées pour les décrire sont
ice_road=yessurface=ice

Pierre 
 

Le lundi 19 novembre 2018 17 h 20 min 53 s HNE, john whelan 
 a écrit :  
 
 Sounds perfect.
Thanks John
On Mon, 19 Nov 2018, 5:07 pm Yaro Shkvorets https://wiki.openstreetmap.org/wiki/Key%3Awinter_service

On Mon, Nov 19, 2018 at 4:54 PM john whelan  wrote:

Locally some paths across parks etc are snow cleared some aren't.  The ones 
that are are useful for cycling in the winter.
Any suggestions on tags?
Thanks John___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca



-- 
Best Regards,
          Yaro Shkvorets___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] Import des arrêts d'autobus de l'ARTM

[Pierre Béland]

Bonjour Claude,
Il faut malheureusement être patients avec les imports. A noter, selon la 
procédure de la Fondation OSM, cette consultation, n'est que la première étape. 
Avant d'importer, il faut écrire sur la liste imp...@openstreetmap.org. De là, 
attend une semaine pour donner le temps de réagir.

Indiques que suite à consultation de la communauté sur talk-ca et obtention 
d'autorisation, tu présentes le projet sur import@osm (voir page wiki contenant 
liens vers autorisations, certaines à venir).

Mentionnes le but de l'import et que méthode est décrite sur la page wiki. 
L'import sera fait par quelques contributeurs seulement qui connaissent le 
schéma de données pour les transports.
 
Pierre 
 

Le mercredi 14 novembre 2018 16 h 48 min 48 s HNE, Alouette955 
 a écrit :  
 
 Bonjour, J’ai récemment soumis ici une proposition d’import des arrêts 
d’autobus de l’ARTM pour discussion en attendant l’autorisation des opérateurs 
de réseaux de l’ARTM. Je viens de recevoir l’autorisation du Réseau de 
Transport Métropolitain (exo) et j’ai mis à jour la page proposant l’import:    
https://wiki.openstreetmap.org/wiki/FR:Import_arr%C3%AAts_d%27autobus,_ARTM_Autorit%C3%A9_r%C3%A9gionale_de_transport_m%C3%A9tropolitain
 Ayant reçu des commentaires sur ma méthode et l’ayant adaptée en conséquence 
je vais la mettre en oeuvre à moins d’un dernier commentaire de votre part. 
Merci, Claude___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Exit with name on node *and* destination

[Pierre Béland]

Je ne suis pas favorable à lancer une action MapRoulette. Cela ressemblerait à 
une opération pour imposer un schema OSM particulier, voire pour mieux 
contrôler le rendu sur la carte.

J'ai modifié au cours des dernières années ces objets et les noms y sont 
revenus. Peut-être vaut-il mieux alerter les communautés locales et leur 
laisser le temps de décider quoi faire ?
Pierre

   Le mardi 6 novembre 2018 14 h 12 min 01 s HNE, Martijn van Exel 
 a écrit : 

 I did create a MapRoulette challenge to review these named junction nodes for 
the United States just now. See 
https://maproulette.org/mr3/challenge/3253/task/588146c. If you find it useful 
I’d be happy to create one for Canada as well. Or show you how you can do it 
yourself.

Martijn  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Exit with name on node *and* destination

[Pierre Béland]

Petit test rapide avec Overpass. J'observe que les clés suivantes sont 
utiliséeshighway=serviceservice=emergency_accessaccess=noexemple 
https://www.openstreetmap.org/way/19692719
La Requête Overpass ci-dessous avec paramètre around, détecte les voies de 
service à proximité d'autoroutes sans clé  service=emergency_access ou 
access=no.  Sélection d'un grand bbox requiert long délais d'exécution.  Et 
d'autres chemins de service se retrouvent dans les résultats, notamment les 
voies de service pour haltes routières.
https://www.openstreetmap.org/way/20057142#map=16/44.8089/-73.4450 
Pierre 
 

Le mardi 6 novembre 2018 10 h 33 min 37 s HNE, Martijn van Exel 
 a écrit :  
 
 Is there an Overpass or other query that could detect all these situations? I 
could make a MapRoulette challenge out of them so we can look at them together 
and remove the name on nodes where it's not appropriate / redundant.

I'll ask on IRC as well.. I am not that much of an expert in Overpass.
-- 
  Martijn van Exel
  m...@rtijn.org

On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote:
> Yep, so in this case removing the name and keeping the ref on the
> junction node sounds appropriate.
> 
> While we're at it, the service road
> https://www.openstreetmap.org/way/48154169 doesn't seem to show up on
> any of the current imagery in iD. Does it still exist?
> 
> --Jarek
> 
> On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote:
> >
> > Je disais précédemment
> > > Je ne sais pour les autres provinces, mais au Québec les no. de sorties
> > > correspondent aux bornes kilométriques de la route (ici 15 pour km 15).
> > > Il est plus informatif d'afficher le no de sortie (ref=15)
> >
> >
> > Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur 
> > la carte, la numérotation de la sortie était «noyée» sous le texte.
> >
> >
> > Pierre
> >  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Exit with name on node *and* destination

[Pierre Béland]

C'est un Import Canvec. Je ne sais pas quelle est la règle pour ces chemins de 
service de façon générale sur les autoroutes. Les ajoute-t-on systématiquement. 
Si oui, il faudrait ajouter access=no, et sans doute emergency=yes.

Je vois une telle route de service 1km plus au sud, au km 10.  

 
Pierre 
 

Le lundi 5 novembre 2018 20 h 24 min 32 s HNE, Jarek Piórkowski 
 a écrit :  
 
 Yep, so in this case removing the name and keeping the ref on the
junction node sounds appropriate.

While we're at it, the service road
https://www.openstreetmap.org/way/48154169 doesn't seem to show up on
any of the current imagery in iD. Does it still exist?

--Jarek

On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote:
>
> Je disais précédemment
> > Je ne sais pour les autres provinces, mais au Québec les no. de sorties
> > correspondent aux bornes kilométriques de la route (ici 15 pour km 15).
> > Il est plus informatif d'afficher le no de sortie (ref=15)
>
>
> Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur la 
> carte, la numérotation de la sortie était «noyée» sous le texte.
>
>
> Pierre
>  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Exit with name on node *and* destination

[Pierre Béland]

Je disais précédemment> Je ne sais pour les autres provinces, mais au Québec 
les no. de sorties 
> correspondent aux bornes kilométriques de la route (ici 15 pour km 15). 
> Il est plus informatif d'afficher le no de sortie (ref=15) 

Ici c'est sortie 11pour km 11,  et non 15 comme j'ai dit précédemment. Sur la 
carte, la numérotation de la sortie était «noyée» sous le texte.

 
Pierre 

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

Re: [Talk-ca] Exit with name on node *and* destination

[Pierre Béland]

Je ne sais pour les autres provinces, mais au Québec les no. de sorties 
correspondent aux bornes kilométriques de la route (ici 15 pour km 15). Il est 
plus informatif d'afficher le no de sortie (ref=15) sur cette node et d'éviter 
d'ajouter le nom de chemin(s) de destination. La destination apparait plutot 
sur le chemin juste après cette node tel qu'il a été fait ici.  Destination= 
Montée Henrysburg

https://www.openstreetmap.org/way/39158262#map=15/45.1094/-73.4699
Il y a quelques années, on voyait souvent le nom sur la node highway_jonction. 
Je pense qu'il est plus approprié de ne mettre que ref. Et les outils de 
navigation savent identifier la clé destination et indiquer le nom des 
destinations pour cette sortie.

voir https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_junction
 
Pierre 
 

Le lundi 5 novembre 2018 15 h 00 min 57 s HNE, Jarek Piórkowski 
 a écrit :  
 
 I have seen this used in Germany for "junction names", e.g.
https://www.openstreetmap.org/node/30249931 is one of the exits making
up "Frankfurter Kreuz" which is the major interchange near Frankfurt
and has its own (quite extensive) Wikipedia page:
https://de.wikipedia.org/wiki/Frankfurter_Kreuz

I don't know if naming interchanges is common in Quebec. The nearest
thing to named interchanges I can think of off the top of my head in
Ontario is the Basketweave on the 401. This example might be a bit of
tagging for the renderer to get the exit name to show up on the
default OSM.org layer.

--Jarek
On Mon, 5 Nov 2018 at 14:47, Martijn van Exel  wrote:
>
> Hi,
>
> I just came across this
>
> https://www.evernote.com/l/AVCmW6jzawZAoqDxpQTxFydcW-0mCP1Lyqw
>
> The exit _link[0] has destination tagging that reflects what is on the exit 
> sign[1], which is correct.
> But the junction node[2] also has the same destination name in its name tag. 
> Is there some special tagging case that I am missing or should the name tag 
> be removed in this case?
>
> Martijn
>
> [0] https://www.openstreetmap.org/way/39158262#map=16/45.1090/-73.4694
> [1] http://openstreetcam.com/details/1153269/386/edit-osm
> [2] https://www.openstreetmap.org/node/147228435#map=16/45.1090/-73.4667
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] Stats Canada new building outlines Open Data do we wish to import it?

[Pierre Béland]

Pour le Québec, je retrouve les données de plusieurs municipalitésMontréal, 
Longueuil, Repentigny, Shawinigan, Québec et Rimouski.
Première observation rapide, aussi, elles sont de bonne qualité et proviennent 
je suppose des cadastres des municipalités. En milieu urbain, cela facilite 
beaucoup l'identification des immeubles juxtaposés.
Je vois ailleurs, aux États-Unis notamment avec les données de Microsoft, que 
les projets sont par région ou municipalité. 

Je pense qu'il faut éviter un projet trop centralisé tant pour assurer un 
meilleur contrôle du déroulement dans chaque municipalité, région que pour 
permettre aux communautés des provinces et communautés locales de s'impliquer. 

La rédaction d' une page wiki pour l'ensemble du Canada peut répondre aux 
exigences du groupe Import de OSM. Mais l'organisation doit être décentralisée.
Le rôle de cette liste doit être un forum pour supporter les communautés des 
provinces et communautés locales. C'est une occasion de dynamiser ces 
communautés avec un projet très intéressant. De là, ils auront le goût de 
compléter la carte pour y décrire les infrastructures locales.  

Si trop de tâches sont initiées en parallèle sur un gestionnaire de tâches, il 
sera très difficile de coordonner, assurer le suivi, une progression 
coordonnée. Il faut éviter que des mapathons ou organisations externes 
s'invitent pour collaborer à de telles tâches avec les milliers et milliers de 
personnes qui viennent jardiner quelques heures sans organisation / formation 
réelle et laissent ensuite le tout sans dessus, dessous. 
Pierre 
 

Le vendredi 2 novembre 2018 16 h 07 min 40 s HAE, James 
 a écrit :  
 
 From my initial glance at the data...seems pretty good and accurate(again I 
didn't check all the cities nor do I expect them all to be having same level of 
accuracy)
The two I've been eye balling are Kingston and Rimouski which seem to be very 
accurate at first assessment. If we do want to import them, a formal draft up 
will have to be done though
On Fri., Nov. 2, 2018, 3:53 p.m. john whelan https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] Open Database of Buildings / Base de données ouvertes sur les immeubles

[Pierre Béland]

Merci Javi
Comme mon hébergeur est au Canada, cela serait surprenant.
 
Pierre 
 

Le vendredi 2 novembre 2018 17 h 15 min 56 s HAE, Javi Rodriguez 
 a écrit :  
 
 Hi Pierre, 

Maybe your internet provider has bad connections with Canadian/US carriers.

I mirrored all the data for you. Download it here:
https://www.illot.cat/ODB/

Salutations,
Javi

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

Re: [Talk-ca] Open Database of Buildings / Base de données ouvertes sur les immeubles

[Pierre Béland]

merci,
ip... téléchargement ok, moins de 2min pour chaque fichier.

 
Pierre 
 

Le vendredi 2 novembre 2018 16 h 39 min 55 s HAE, Javi Rodriguez 
 a écrit :  
 
 Hi Pierre,

I did not found any problem with the StatCan website.
I mirrored those files only to test your connection. Test it:

https://www.illot.cat/ODB/BDOI_Quebec.zip
https://www.illot.cat/ODB/ODB_Quebec.zip

Salutations,
Javi

‐‐‐ Original Message ‐‐‐
 On Friday, November 2, 2018 3:38 PM, Pierre Béland  wrote:
 

Bonjour Alessandro

Je rencontre depuis hier des problèmes à télécharger les fichiers pour le 
Québec (fr ou en). Je ne suis sans doute pas le seul et les navigateurs ne nous 
offrent pas d'outils pour reprendre les transferts interrompus ou bien 
diagnostiquer les problèmes, sinon message Échec de transfert.  Le transfert 
est lent et interrompu après plusieurs minutes. Il est possible que votre 
serveur soit surchargé. Dans un tel contexte, il serait sans doute mieux de 
subdiviser les fichiers pour chaque ville ou zone à l'intérieur d'une province.

J'ai testé depuis hier avec les navigateurs Firefox et Chrome et rencontre des 
problèmes d'interruption de transfert avec chacun.  Je n'ai généralement pas de 
problème et ai une bonne connexion internet. 

liens url testés
https://www.statcan.gc.ca/sites/default/files/upload/media/BDOI_Quebec.zip
https://www.statcan.gc.ca/sites/default/files/upload/media/ODB_Quebec.zip 
Pierre 

Le jeudi 1 novembre 2018 14 h 07 min 17 s HAE, Alasia, Alessandro (STATCAN) 
 a écrit :


Released today!  / Diffusée aujourd’hui  
Share with your networks ! / Partagez avec vos réseaux !
 
 
***(EN)
Open Building Data: an exploratory initiative
This exploratory initiative aims at enhancing the use and harmonization of open 
building data from government sources for the purpose of contributing to the 
creationof a complete, comprehensive and open database of buildings in Canada. 
The outcome of this exploratory work is a first version of the Open Database of 
Buildings (ODB),a centralized and harmonized repository of building data made 
available under the Open Government License - Canada.
This initiative originates from insights taken from the StatisticsCanada pilot 
project on data crowdsourcing, which used OpenStreetMap as a platform for 
integrating data on building footprints. In addition to the possible benefits 
of crowdsourcing, that project highlighted the potential of integrating 
opendata from municipal, regional, and provincial governments to meet the needs 
of official statistics.
In its current version (version 1.0), the ODB contains approximately 4.3 
million building footprints.
https://www.statcan.gc.ca/eng/open-building-data/index
Open Database of Buildings (ODB),
 
*** (FR)
Données ouvertes sur les immeubles : une initiative exploratoire
Cette initiative exploratoire vise à accroître l'utilisation et l'harmonisation 
des données ouvertes sur les immeubles provenant de sources gouvernementales en 
vue decontribuer à la mise en œuvre d'une base de données complète, exhaustive 
et ouverte sur les immeubles au Canada. Le travail exploratoire a mené à la 
création d'une première version de la Basede données ouverte sur les immeubles 
(BDOI), un référentiel centralisé et harmonisé des données sur les immeubles 
rendu public en vertu de la Licencedu gouvernement ouvert du Canada.
Cette initiative est fondée sur les leçons tirées du projetpilote de 
Statistique Canada sur l'approche participative en matière de données, qui 
avait employé OpenStreetMap comme plateforme d'intégration des données sur les 
empreintes d'immeubles. En plus des avantages potentiels de l'approche 
participative,ce projet a mis en lumière la possibilité d'intégrer les données 
ouvertes des administrations publiques municipales, régionales et provinciales 
afin de répondre aux besoins en matière de statistiques officielles.
Dans sa version actuelle (version 1.0), la BDOI contient environ 4,3 millions 
d'empreintes d'immeubles.
https://www.statcan.gc.ca/fra/donnees-ouvertes-immeubles/index
 
Base de données ouverte sur les immeubles (BDOI)
 
 
Alessandro Alasia 
 Chief | ChefData Exploration and Integration Lab (DEIL) | Lab pour 
l’exploration et l’intégration de données (LEID)
Center for Special Business Projects | Centre des Projets Spéciaux sur les 
entreprises
Statistics Canada | Statistique Canada
 alessandro.ala...@canada.ca / (613) 796-6049 
 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


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

Re: [Talk-ca] Open Database of Buildings / Base de données ouvertes sur les immeubles

[Pierre Béland]

Bonjour Alessandro
Je rencontre depuis hier des problèmes à télécharger les fichiers pour le 
Québec (fr ou en). Je ne suis sans doute pas le seul et les navigateurs ne nous 
offrent pas d'outils pour reprendre les transferts interrompus ou bien 
diagnostiquer les problèmes, sinon message Échec de transfert.  Le transfert 
est lent et interrompu après plusieurs minutes. Il est possible que votre 
serveur soit surchargé. Dans un tel contexte, il serait sans doute mieux de 
subdiviser les fichiers pour chaque ville ou zone à l'intérieur d'une province.
J'ai testé depuis hier avec les navigateurs Firefox et Chrome et rencontre des 
problèmes d'interruption de transfert avec chacun.  Je n'ai généralement pas de 
problème et ai une bonne connexion internet. 

liens url testés
https://www.statcan.gc.ca/sites/default/files/upload/media/BDOI_Quebec.zip
https://www.statcan.gc.ca/sites/default/files/upload/media/ODB_Quebec.zip 
Pierre 
 

Le jeudi 1 novembre 2018 14 h 07 min 17 s HAE, Alasia, Alessandro (STATCAN) 
 a écrit :  
 
  Released today!  / Diffusée aujourd’hui   Share with your networks ! / 
Partagez avec vos réseaux !  ***(EN)Open Building Data: an exploratory 
initiativeThis exploratory initiative aims at enhancing the use and 
harmonization of open building data from government sources for the purpose of 
contributing to the creationof a complete, comprehensive and open database of 
buildings in Canada. The outcome of this exploratory work is a first version of 
the Open Database of Buildings (ODB),a centralized and harmonized repository of 
building data made available under the Open Government License - Canada.This 
initiative originates from insights taken from the StatisticsCanada pilot 
project on data crowdsourcing, which used OpenStreetMap as a platform for 
integrating data on building footprints. In addition to the possible benefits 
of crowdsourcing, that project highlighted the potential of integrating 
opendata from municipal, regional, and provincial governments to meet the needs 
of official statistics.In its current version (version 1.0), the ODB contains 
approximately 4.3 million building footprints. 
https://www.statcan.gc.ca/eng/open-building-data/indexOpen Database of 
Buildings (ODB), *** (FR)Données ouvertes sur les immeubles : une initiative 
exploratoireCette initiative exploratoire vise à accroître l'utilisation et 
l'harmonisation des données ouvertes sur les immeubles provenant de sources 
gouvernementales en vue decontribuer à la mise en œuvre d'une base de données 
complète, exhaustive et ouverte sur les immeubles au Canada. Le travail 
exploratoire a mené à la création d'une première version de la Basede données 
ouverte sur les immeubles (BDOI), un référentiel centralisé et harmonisé des 
données sur les immeubles rendu public en vertu de la Licencedu gouvernement 
ouvert du Canada.Cette initiative est fondée sur les leçons tirées du 
projetpilote de Statistique Canada sur l'approche participative en matière de 
données, qui avait employé OpenStreetMap comme plateforme d'intégration des 
données sur les empreintes d'immeubles. En plus des avantages potentiels de 
l'approche participative,ce projet a mis en lumière la possibilité d'intégrer 
les données ouvertes des administrations publiques municipales, régionales et 
provinciales afin de répondre aux besoins en matière de statistiques 
officielles.Dans sa version actuelle (version 1.0), la BDOI contient environ 
4,3 millions d'empreintes 
d'immeubles.https://www.statcan.gc.ca/fra/donnees-ouvertes-immeubles/index Base 
de données ouverte sur les immeubles (BDOI)  Alessandro Alasia 
Chief | ChefData Exploration and Integration Lab (DEIL) | Lab pour 
l’exploration et l’intégration de données (LEID)Center for Special Business 
Projects | Centre des Projets Spéciaux sur les entreprisesStatistics Canada | 
Statistique Canada
alessandro.ala...@canada.ca / (613) 796-6049  
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Import des arrêts d'autobus de l'ARTM

[Pierre Béland]

Bonjour Claude, 

Je connais peu les relations pour itinéraires de services de transport.
Le groupe de discussion Import de OSM suit de très près tout import. Et la 
question de licence c'est toujours très litigieux. Si pas indiqué OdBL, il faut 
habituellement une autorisation écrite permettant spécifiquement à OSM 
d'utiliser les données.
Licences ; À première vue RTL Longueuil et STL Laval ont la même licence avec 
un libellé indiquant que pas pour fin commerciales 
-> Automatiquement, cela est non conforme à OdBL et donc il faudrait une 
autorisation écrite
 
Pierre 
 

Le vendredi 19 octobre 2018 13 h 55 min 35 s HAE, Alouette955 
 a écrit :  
 
 Bonjour, Il y a quelques temps je lançais une consultation sur ma proposition 
d’import pour les arrêts d’autobus du Réseau de transport Métropolitain, 
maintenant EXO. J’attends incessamment leur autorisation pour l’import avec 
mention sur la page des contributeurs.    
https://wiki.openstreetmap.org/wiki/FR-Import_arr%C3%AAts_d%27autobus,_EXO_r%C3%A9seau_de_transport_m%C3%A9tropolitain
 Tout commentaire sur ma méthodologie est bienvenue. Depuis j’ai compris que 
EXO, tout comme la STM (Montréal), la STL (Laval) et le RTL (Longueuil) sont 
des opérateurs distincts mais qui collaborent sous l’égide de l’ARTM. Un peu 
compliqué mais maintenant clarifié. J’en ai profité pour créer une page pour 
l’ARTM dans le wiki:   
https://wiki.openstreetmap.org/wiki/FR-ARTM_-_Autorit%C3%A9_r%C3%A9gionale_de_transport_m%C3%A9tropolitain
 La STL et le RTM ont une licence qui me semble beaucoup plus permissive:   
http://www.rtl-longueuil.qc.ca/fr-CA/donnees-ouvertes/  
https://www.stl.laval.qc.ca/fr/stl-synchro/developpeurs/ (voir à l’encadré 
Conditions d’utilisation) Je songe donc les inclure à mon projet d’import sans 
autre formalité autre de les indiquer dans la page des contributeurs. La 
question est: Aie-je bien compris ces licences?  Il ne me semble pas que 
l’import dans la base de données OSM est une utilisation commerciale ou quasi 
commerciale mais peut-être y a-t-il un précédent qui m’obligerait à obtenir une 
autorisation spécifique. Merci, Claude 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [OSM-talk-fr] Numéro de tuile ?

[Pierre Béland]

Bonjour Hélène,
Perso, j'aime voir sous forme de grille et ai ajouté à la carte osm-pixels le 
calque «Grille osm z, x, y»Avec le bouton droit de la souris, il est aussi 
possible de faire un dirty de la tuile. Utile pour zoom inférieur à 13 mais pas 
toujours effectif.
https://pierzen.dev.openstreetmap.org/osm-pixels/#10/48.747074/2.242224
 
Pierre 
 

Le vendredi 14 septembre 2018, Hélène Petit   a 
écrit :  
 C'est quoi le truc pour connaître le numéro d'une tuile affichée dans 
OpenStreetMAp.org ?

Merci !

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

[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-fr] [Hot-francophone] [Tagging-fr] Tags à Madagascar - Praticabilité des routes en priorités

[Pierre Béland]

Les outils de navigation routière se basent sur des éléments tels surface et 
practicability.  Pour une tell route, j'indiques habituellement surface=dirty, 
practicability=horrible. Et le horrible tient évidemment compte des dommages 
causés par la pluie et le traffic routier la rendant inpraticable - par exemple 
camions remorques.Exemple parlant 
https://twitter.com/irinnews/status/954452916483559424
 
Pierre 
 

Le vendredi 8 juin 2018 09 h 30 min 59 s HAE, Lukas Sommer 
 a écrit :  
 
 Salut Violaine.

> Est-ce que tu pourrais donner un peu plus d’élément, quel est ton moyen de
> locomotion, qu’est ce qui fait que la route n’est pas praticable ?
> inondations ? trop de gros trous ? dégradée un peu plus entre 2 passages ?

Voiture 4 × 4 ou voiture ordinaire ou moto.

Le plus grand problème est la boue : La surface de la route est très
moue, la voiture s’enfonce est ne peut plus sortir. Cela est
particulièrement fréquent en saison pluvieuse, parce que la route est
encore mouillée de la dernière pluie, et maintenant, très peu de pluie
est suffisante pour la rendre impraticable. (Parfois, il pleut dans
une partie de la ville, mais ne pas dans une autre partie, donc il
faut voir cas par cas.)

Le deuxième problème ce sont des passages ou il y a trop d’eau. Si
c’est plus de 30 cm d’eau sur le sol, ça devient compliqué. Le
problème des passages submergés dépend fortement d’où exactement la
pluie est tombée, est pour où l’eau est évacuée. Aussi en ville la
canalisation est parfois ne pas en bon état, ce que causent des
inondations sur des passages normalement bien praticables.

Le troisième problème c’est qu’après une forte pluie, souvent les
trous sont plus grands, et cela parfois rend impraticable une route
pendant des mois, parce que les dégâts ne sont pas réparés tôt.

> A Madagascar
> pour 2 routes en terre, l’une peut être nationale praticable en voiture,
> l’autre être une route qui s’enfonce dans la brousse et nécessité d’avoir un
> 4x4 voire treuil.

Oui. La page wiki https://wiki.openstreetmap.org/wiki/FR :
Highway_Tag_Africa est une très bonne description de la situation : Si
une route est « primary » ou « unclassified » ne dépend pas de son
état ou de sa surface, mais uniquement de son importance dans le
réseau routier. On peut trouver dans le même pays des routes «
unclassified » goudronnées et des routes « primary » non-goudronnée.
Et effectivement, c’est aussi le cas en Côte d’Ivoire. Ladite page
wiki a aussi quelques autres astuces utiles pour les routes en mauvais
état. (À mon avis, ce qui est décrit sur cette page est très bien
formulé et ne vaut pas seulement pour l’Afrique, mais aussi pour le
reste du monde.)

Au fait nous avons développé pour openstreetmap-carto une possibilité
de visualiser la clé « surface ». Avec un peu de chance, ça sera
visible sur openstreetmap.org dans peut-être deux mois…

> quand on prend du recul, qu’on regarde une zone
> entière on va voir les tronçons de routes

> Par contre, vu que notre problème à nous (a Vatomandry)
> c’est les ponts, on pourrait penser (car à cette échelle on va pas voir les
> coupure d’itinéraire / les ponts qui manquent) que c’est possible d’aller à
> un tel ou tel endroit alors que c’est pas possible.

D’accord, J’ai bien compris le problème maintenant : Le calcul
d’itinéraire marche comme il faut, mais tu as besoin d’une
visualisation sur une carte qui de montre d’un seul coup d’œil des
zones accessibles et non-accessibles.

> Donc j’imaginais passer
> par une relation, un genre d’itinéraire voiture composé de ponts si yen a et
> de tronçon de routes et qualifier l’ensemble de l’itinéraire.

Cette idée je ne l’ai pas encore bien compris.

> Ce que j’aimerais c’est mettre en lumière et rendre accessible cette infos à
> tous, tous les itinéraires qui ne sont pas accessibles à cause de manque de
> ponts (c’est impressionnant).

Je n’ai pas d’expérience avec cela. Mais à
https://wiki.openstreetmap.org/wiki/Isochrone tu trouve une
introduction dans des calculs de ce genre. Et à
https://tools.geofabrik.de/osmi/ tu trouve des analyses géométriques
pour OSM. Choisis « View : Routing » et après, à gauche dans le
registre « Overlays » tu désactives tous sauf « Islands ». Peut-être
cela peut t’aider.

À bientôt !

___
Hot-francophone mailing list
hot-francoph...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot-francophone
  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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." 

Re: [Talk-ca] Question

[Pierre Béland]

Pier Luc,

Nous ne pouvons importer systématiquement dans OSM les Codes postaux, Poste 
Canada prétendant avoir un copyright la-dessus. Mais il est possible pour une 
adresse particulière (un node avec clé addr:housenumber) d'y ajouter aussi un 
code postal.  On retrouve aussi des lignes d'interpolation d'adresse. C'est de 
cette façon que OSM repère le 2985 rue de la Broussaille
voir https://www.openstreetmap.org/way/104093690Cette ligne débute au 2945
https://www.openstreetmap.org/node/1201135774et se termine au 
https://www.openstreetmap.org/node/1201130753
Si tu mettais à jour ces deux nodes en y ajoutant addr:postcode=G2C 1S1
Le bon code postal serait disponible rapidement sur le site. Par contre les 
délais de mise à jour des fichiers obf varie selon chaque éditeur de logiciel.

Une bonne façon pour toi comme collaborateur de Québec de mettre la main à la 
sauce!
Pour ce qui est des résultats lors de la recherche d'adresses, chaque logiciel 
a sa propre méthode. Et les logiciels sur téléphone ou tablette doivent 
économiser l'espace disque.  Méthode sans doute simplifiée.

Tu peux essayer le logiciel Maps.Me disponible pour Android et Apple. Et 
comparer si différent de OsmAND.
 
Pierre 
 

Le vendredi 27 avril 2018 17 h 26 min 56 s HAE, john whelan 
 a écrit :  
 
 Post codes are put in one at a time.  They aren't all there.
If you could help clean them up that would be useful.
Zip codes are different and belong in Donald's land.
Cheerio John



On Fri, 27 Apr 2018, 5:01 pm Pier Luc,  wrote:

Hello, I live in Quebec City. I tried to use OSMand (based on OSM) in my City 
using offline mode and the OBF file of the Province of Quebec. Every time I 
search an address it can not find it! Sometime it offer me other address, 
sometime not. It's like if only a tiny part of Quebec's address had been insert 
in Open Street Map. But, it's not exactly the case because is has more address 
in Open street Map website.

Look at that example, searching: 2985 rue de la Broussaille.
Osmand can't find it by OSM web site gives:
Maison 2985, Rue de la Broussaille, Neufchâtel-Est, Les Méandres, Québec, 
Québec (Agglomération), Capitale-Nationale, Québec, G2C 0G3, Canada

I think it has a problem there. A lot of information should not be there and 
the zip code is bad. It should be G2C 1S1. If that address is in the OBF, I 
supposed the app have difficulties to find it.

The good address is: 2985, Rue de la Broussaille, Québec, QC, G2C 1S1, Canada




An other test: 920, rue Noël-Carter


Osmand can't find it but OSM web site can:



École Centre de formation professionnelle Maurice-Barbeau, 920, Rue 
Noël-Carter, Sainte-Foy, Québec, Québec (Agglomération), Capitale-Nationale, 
Québec, G1V 1X3, Canada

The good address is


CFP Maurice-Barbeau
920, Rue Noël-Carter, Québec, QC, G1V 5B6, Canada

An other zip code error and an other address full of "dust".

Every-time I tried to find something it's the same thing. It's impossible to 
use Osmand as a GPS in Quebec City. I think it's because the data in the OBF of 
the Province of Quebec is bad.

Is your work have been put in the OBF? Does is exist and other OBF for the 
Province of Quebec than the OF we can find there?
https://download.osmand.net/list.php

Tank-you




   

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

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

[Talk-ca] Réserves, gestion de la faune

[Pierre Béland]

Le contributeur webfil a fait un excellent travail au Québec de cartographier 
les différentes réserves naturelles et territoires de la gestion de la faune. 
Si vous regardez la carte du Québec, vous verrez que ceci comprend de larges 
portions du territoire dans les zones forestières.

Je ne sais ailleurs au Canada, mais au Québec en plus des parcs nationaux et 
réserves strictes de protection de la faune, écologie ou autre, il y a deux 
catégories supplémentaires des territoires publics de gestion de la faune 
(activités de chasse et pêche). Ces territoires sont souvent aussi grands que 
les parcs nationaux.- Zec - gestion par une association
- Pourvoiries - concession de l'exploitation d'un territoire à une entreprise 
privée

Suite à la discussion sur le changeset 
https://www.openstreetmap.org/changeset/53933324#map=8/49.465/-62.898, je 
poursuis ici.

Webfil a classifié 
parc national : boundary=national_parc, leisure=nature_reserve
ZEC: boundary=protected_area, protected_class=7, leisure=national_reserve
Réserve faunique: boundary=protected_area, protected_class=4, 
leisure=national_reserve
Réserve écologique: boundary=protected_area, protected_class=1, 
leisure=national_reserve
Pourvoiries : landuse=commercial

La classification pour les pourvoiries m'apparait inadéquate. On pourrait soit 
classifier de façon similaires aux ZEC, soit indiquer uniquement 
leisure=nature_reserve.

En comparaison, je vois en Colombie-Britannique, un territoire classifié 
leisure=nature_reserve
Relation : Dewdrop-Rosseau Wildlife Management Area (2238697)
 
Pierre 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Limites de territoires - Suivi et mise à jour via JOSM

[Pierre Béland]

L'ajout de limites de territoires par les contributeurs canadiens a beaucoup 
progressé au cours de derniers mois.  La carte Osmose permet de visualiser le 
différents niveaux hiérarchiques de territoires complétés pour un pays ou 
région (voir 
http://osmose.openstreetmap.fr/fr/map/#zoom=7=7.28=-4.845==1%2C2===FFTTTFFFT).
À noter que ce travail d'édition doit être fait par des contributeurs 
expérimentés. Et il faut les bons outils. Voici un petit tutoriel où je partage 
mon expérience. J'y décrit également le Style «Admin Boundaries» que j'ai 
ajouté aux Styles JOSM.
Le lien Osmose ci-dessous permet de lister les erreurs pour un pays / région 
donné. Pour chaque erreur, il est possible d'importer les données de cet objet 
directement dans JOSM pour correction en cliquant sur chaque hyperlien.
Exemple 
https://osmose.openstreetmap.fr/fr/errors/?country=ivory_coast=100=1060%2C6010%2C6060
Le style JOSM  Admin_Boundaries que je viens d'ajouter facilite lui l'édition 
dans JOSM.  Il y affiche une carte similaire à Osmose lorsque l'on fait un 
zoom-out, ce qui perment de voir rapidement les zones complétées ou non.  

Pour l'édition dans JOSM, il est possible de travailler avec un ou plusieurs 
niveaux hiérarchiques simultanément. Tout comme dans Osmose, chaque niveau 
hiérarchique est coloré différemment. Aussi, lorsque l'on zoom en détail, 
différent éléments sont mis en évidence pour faciliter l'édition (ie. noeuds de 
connection, chemins non fermés, etc.).
On ajoute ce style dans JOSM à partir du panneau Coloriage1. Sélectionner les 
Préférences (F12)2. Cliquer dans la colonne de gauche sur le 3ième bouton, puis 
sur Coloriage.3. Rafraichir la liste des Styles disponibles en cliquant sur le 
bouton au bas du panneau de Styles disponibles4. Sélectionnez le style 
Admin_Boundaries.Ce style est aussi décrit à l'adresse 
https://josm.openstreetmap.de/wiki/Styles/Admin_Boundaries
Voici un exemple dans JOSM à l'aide d'une requête Overpass pour les limites 
territoriales de Chaudière-Appalaches au Québec. La requête ci-dessous est 
simplement copiée dans la fenêtre de droite (Overpass) du panneau de 
téléchargement JOSM.  Il faut cependant être conscient que l'on ne télécharge 
qu'une partie des données. Cela peut créer des conflits d'édition. Il faudra 
donc s'assurer de ne pas détruire des données telles rivières, routes, etc 
faisant partie des relations de territoire.  On doit aussi recharger les 
données avant le téléchargement vers le serveur pour s'assurer que de nouvelles 
données n'ont pas été ajoutées très récemment et valider s'il y a des conflits 
d'édition.

[out:xml][timeout:40];
 {{geocodeArea:"Chaudiere-Appalaches"}}->.territoire;
  (
  relation["boundary"](area.territoire);
 );
out meta;
>;
out meta;

Après le téléchargement,  les paramètres d'option du style Admin Boundaries 
nous permettent de sélectionner le ou les niveaux administratifs à afficher. 
Voir sur twitter exemple pour la Côte d'Ivoire 
https://twitter.com/pierzen/status/983089154115465217
Pour ce pays, nous pouvons par exemple sélectionner les niveaux 4, 5 et 6. On 
clique sur le style Admin Boundaries dans le panneau coloriage à droite avec le 
bouton droit de la souris, puis sur «Paramètres de style». On sélectionne un 
niveau hiérarchique. Pour en afficher plusieurs simultanément, on répète la 
sélection pour pour chacun.

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

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: [Talk-ca] Trans-Canada Highway research

[Pierre Béland]

Martijn
Si je comprends bien ton message, tu proposes que la communauté canadienne 
accepte de réaliser les projets de Telenav, sinon, votre équipe prendra le 
contrôle ?  À mon avis, cette proposition ignore le rôle des communautés 
locales dans le projet OSM, et le réduit à celui d'exécutants.

Les commentaires des contributeurs canadiens allaient tous dans le même sens. 
Nous ne comprenons pas ce que vous visez exactement. Si une simple relation 
Transcanadienne répond à vos besoins, je penses que vous pouvez le réaliser 
facilement. 
Par contre, les contributeurs canadiens ont exprimé leur désaccord à ce que 
vous modifiez systématiquement les routes pour normaliser les noms selon les 
besoins de votre équipe. 
Pierre 
 

Le mercredi 28 mars 2018 15 h 43 min 31 s HAE, Martijn van Exel 
 a écrit :  
 
 Pierre, 

Consistency in the data is the main goal. This benefits all the things you 
mention, including map rendering and parsing by navigation software such as 
ours but also OSMAnd, maps.me and others.
There is a master relation for the Trans-Canada Highway / Route 
Transcanadienne[0] but it is incomplete and broken. One idea would be to repair 
it, and the province-level relations that would be the members of it. Would you 
be interested in coordinating that?

[0] https://www.openstreetmap.org/relation/1307243
--
  Martijn van Exel
  m...@rtijn.org
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Trans-Canada Highway research

[Pierre Béland]

Bonjour Martin,
Il me semble que les divers commentaires ont été assez clair. La communauté OSM 
du Canada est assez mature pour gérer cela et n'avons pas besoin que Navteq 
démarre un projet pour modifier ces données.
L'équipe Navteq a déja créé beaucoup de problèmes en ajoutant partout des 
relations complexes pour un simple interdit de faire un virage en U.  Quels 
sont maintenant les objectifs de la tâche
 More Overlapping Ways in CanadaTelenav OSM Integrity Checks's Project
A mon  avis, vous devez discuter avec la communauté canadienne avant de 
démarrer de tels projets. Svp interrompre cette tâche et venez en discuter.

Et quels sont vos objectifs pour les modifications vs la route Trancanadienne? 
Un meilleur rendu sur la carte, des itinéraires dans les outils de navigation ? 
Pourquoi ne pas simplement créer une relation de type route pour la route 
Transcanadienne?

 
Pierre 
 

Le mercredi 28 mars 2018 13 h 23 min 37 s HAE, Martijn van Exel 
 a écrit :  
 
 Hi all, 

My colleague Olivia will respond more in depth with some suggestions based on 
your feedback. Thanks for giving our team's ideas some thought.

In the meantime, as I was writing a post about the new version of MapRoulette, 
I thought I'd make a Challenge for misspelled Trans-Canada Highway names. 
Please find it here: http://maproulette.org/mr3/browse/challenges/2955 . 
There's only a little over 200 tasks, so that should be an easy thing to fix 
together. 

The Challenge is based on this Overpass query: http://overpass-turbo.eu/s/xoW 
-- it's pretty easy to make your own Challenges based on your own Overpass 
queries or GeoJSON files.

The diary post explaining MapRoulette is here: 
https://www.openstreetmap.org/user/mvexel/diary/43596

Thanks,--
  Martijn van Exel
  m...@rtijn.org



On Tue, Mar 27, 2018, at 07:13, Begin Daniel wrote:


Andrew, Je ne crois pas que le fait que ces ‘contributeurs’ soient Roumains, 
Javanais ou Américains soit à considérer. Ils nous ont consultés avant de faire 
la modification et c’est parfait. Cependant, je suis entièrement en accord avec 
ta réponse - laissez ça à la communauté canadienne!


 


(I do not believe that the fact these ‘contributors’ are Romanians, Javanese or 
Americans is to be considered. They consulted us before making the change and 
it's perfect. However, I fully agree with your answer - leave that to the 
Canadian community!-)


 


Sent from  Mail for Windows 10


 


From: Andrew Lester 
 Sent: Monday, March 26, 2018 1:35:56 PM
 To: Olivia Robu - (p)
 Cc: talk-ca
 Subject: Re: [Talk-ca] Trans-Canada Highway research  
While standardization may be nice, it often won't be possible even within a 
single country. As has already been discussed, there are differing conventions 
in different provinces, so please don't try to apply a single plan to all 
provinces. How the TCH is handled in OSM will vary depending on the province.

For example, in BC (and some other western provinces), the TCH carries the 1 
ref. In some places where other ref'ed highways coincide with the TCH, the ref 
is recorded as "ref=1;19", for example. There are places within cities where 
the TCH runs on city roads with different names (e.g. Douglas Street in 
Victoria), so those ways are named with the local name and the TCH name is 
recorded in the alt_name or nat_name tag (a separate argument is which one of 
these to use). An alternate name should never be added to the primary name in 
brackets like proposed. That's exactly what the alt_name (and similar) tags are 
for. There are also many places where Trans-Canada Highway is the official 
local name of the road, like most of the highway in BC.

As for the correct spelling of the TCH, I think it would be fairly 
uncontroversial to standardize the name to "Trans-Canada Highway" or "Route 
Transcanadienne" where it's appropriate to use the TCH name, because those are 
the official spellings. Any variants can be considered errors.

As for varying highway classifications, this is correct and to be expected. 
Unlike the US interstate system, the Trans-Canada Highway network varies in 
construction and importance all across the country, so the classification can't 
be standardized to just motorway or trunk. There are sections where primary is 
the most appropriate, and possibly even secondary in some places. Just on 
Vancouver Island alone, the roads designated as the TCH vary from a six-lane 
motorway all the way down to a two-lane effectively-tertiary road.

Since there will need to be a lot of local knowledge required for such a 
project, I strongly recommend that this project not be undertaken by Telenav. 
This is the kind of work that Canadians should be doing, being the most 
familiar with the on-the-ground situation which will dictate how the highway is 
handled in each province. The numerous past issues with Telenav's contributions 
is also a factor that can't be ignored. Does it really make sense for a team of 

Re: [Talk-ca] Trans-Canada Highway research

[Pierre Béland]

Sur la page wiki https://en.wikipedia.org/wiki/Trans-Canada_Highway, on voit 
que des panneaux Transcanada sont ajoutés sur le côté de la route. Cependant, 
au Québec comme en Ontario, les panneaux de navigation au-dessus de la route ne 
font pas de façon générale référence à la Transcanadienne. 
Comme le dit James, la Transcanadienne, c'est une méta-donnée. Une relation de 
type route permettrait de décrire ce réseau.  
Il serait aussi possible d'ajouter une référence à la Transcanadienne dans la 
clé ref. 
Exemple ref=417; TC(TC pour Transcanadienne).
Exemple où trois routes partagent un segment, ref=35; 104; 133.
voir https://www.openstreetmap.org/way/128245108#map=16/45.3227/-73.2309
Au dela du rendu sur la carte, ces références sont-elles utiles aux outils de 
navigation routière? En ajoutant TC, est-ce que l'on indiquerait à chaque fois, 
Continuez sur la route 417, Transcanadienne ?  Le risque est d'ajouter de la 
confusion dans les instructions de navigation.
Quel est l'objectif de l'équipe de Telenav pour harmoniser les références à la 
Transcanadienne et  ajouter les infos proposées ?

 
Pierre 
 

Le lundi 26 mars 2018 12 h 21 min 52 s HAE, James  a 
écrit :  
 
 http://openstreetview.org/details/23187/73
No trans-canada naming in sight because the trans-canada is a meta road 
composed of multiple highways. See road sign in OSV.
On Mon, Mar 26, 2018, 12:07 PM Kevin Farrugia,  wrote:

The proper name for the highways that are under the Kings Highway system 
(400-Series included) is "Highway xxx" or Highway xx, with the exception of the 
QEW.  Highways signs and government data follow the same rules.
The Trans-Canada as a name/deaignation is almost inconsequential in Ontario and 
to Ontarians.

---
Kevin Farrugia

On Mon, Mar 26, 2018, 11:46 AM Viajero Perdido, 
 wrote:

On 18-03-26 05:33 AM, talk-ca-requ...@openstreetmap.org wrote:
> Message: 3
> Date: Mon, 26 Mar 2018 11:33:14 +
> From: James 
> To: "Olivia Robu - (p)" 
> Cc: Talk-CA OpenStreetMap 
> Subject: Re: [Talk-ca] Trans-Canada Highway research
> Message-ID:
>       
> Content-Type: text/plain; charset="utf-8"
>
> highway 417 should be tagged as highway 417 and not principally transcanada
> way as this is how it's known locally. It can be tagged in transcanada
> relation, but it's mainly known as the 417

I disagree.  "Highway 417" is a low-value name, because the "ref" tag
should already contain the number, causing numbered shields to be
shown.  "Highway 417" is just a verbosification of the number.
"Trans-Canada Highway", however, is a real name; it belongs in the name
field.

This way, most maps would show both name and number.

To me, the (completely separate) issue is whether ordinary numbered
highways should have a name tag at all, "Highway nnn", or simply nothing
because "ref" takes care of it.  I've been able to find no guidance on
this, and I've looked.  I've been leaving "Highway nnn" in place when I
see it, which is most of the time.  But that's another discussion for
another day.

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

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

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

[OSM-talk-fr] JOSM - Support HTTPS

[Pierre Béland]

Dirk Stöcker a ouvert un ticket pour lister les divers liens josm (styles, 
imagerie, etc) non encore convertis au protocole https. J'y vois plusieurs 
liens en France.
https://josm.openstreetmap.de/ticket/16123
 
Pierre 
 

   - Message transféré - De : Dirk Stöcker 
À : "josm-...@openstreetmap.org" 
Envoyé : samedi 24 mars 2018 10 h 58 min 36 s 
HAEObjet : Support HTTPS
 Hello,

for some years we are step by step migrating JOSM to https. Many others 
are doing the same, so the https usage is increasing a lot everyday.

Now JOSM server is completely https itself and in the last weeks also 
external resources like maps, styles, plugins, rules, presets step by step 
have been migrated. There are still some hundred links not using https, 
but many hundreds have been fixed already.

To get rid of the remaining ones I created a ticket:
https://josm.openstreetmap.de/ticket/16123

This contains a list of servers, which answer on port 443, but links are 
still in http. Servers who not answer on port 443 are not included!

Please help fixing these entries!

1) Some entries may simply be fixed by switching the link (e.g. these 
with 200 OK message).
  a) If in the wiki simply fix it (and test it!)
  b) If external inform the author and document it in the ticket

2) Some are broken server setups
  a) If an openstreetmap service please inform the authors to fix it and 
document this in the ticket
  b) If not OSM and you know the contacts, ask them friendly to fix it and 
document what you did in the ticket
  c) Otherwise only document the server state in the ticket for later 
checks

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

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

Re: [OSM-talk-fr] Besoin d'aide pour Validation niveaux hiérarchiques Relations type=boundary

[Pierre Béland]

A partir des rapports Osmose, j'ai corrigé les polygones avec croisement sur le 
territoire du Québec. J'y ai rencontré les différentes situations qui causent 
des polygones à se croiser - doublons pour un même segment, chacun utilisé pour 
une relation polygone différente- chemins en parallèle, et un segment du 
premier vient couper le deuxièmeetc.Mais il persiste des cas plus 
problématiques à repérer. J'ai trouvé un rapport de MapQuest sur les polygone 
brisés dans Nominatim. Il n'est cependant plus accessible. Quelqu'un connait ce 
rapport?
MapQuest Broken Polygon Report
https://devblog.mapquest.com/author/deb-tankersley/

Voici un Exemple de hiérarchie de régions administratives qui n'est pas 
reconnue correctement par Nominatim. Les polygones de niveau 4, 5, 6 sont 
fermés et s'emboitent l'un dans l'autre et ont une partie commune au sud-est de 
la frontière. J'ai validé 1 à un les segments communs et ils sont tous ok.

Une recherche Nominatim sur Beauce-Sartigan ignore la relation de niveau 5 et 
retourne comme résultat : Beauce-Sartigan , Québec
4 Québec
5 Chaudière-Appalaches
https://nominatim.openstreetmap.org/details.php?place_id=230577703 6 
Beauce-Sartigan
https://nominatim.openstreetmap.org/details.php?place_id=229206252

Des pistes de solution pour valilder de telles situations? Rapports Nominatim ?

Pierre


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

Re: [OSM-talk-fr] Besoin d'aide pour Validation niveaux hiérarchiques Relations type=boundary

[Pierre Béland]

J'ai confondu les noms de mes intelocuteurs en copiant message. Merci à Marc et 
Vincent.
Mon premier chemins ignalé par Osmose avec près de 1000 noeuds (id=567542271) 
trace la frontière entre le Québec et le Maine aux États-Unis. Ce sont des 
frontières hyper-détaillées et le contributeur a tracé un chemin en parallèle 
pour éviter d'y toucher. Sauf que le nouveau tracé chevauchait à des centaines 
de reprise.
Exténuant, mais au moins j'ai une piste pour progresser et corriger.


 
Pierre 
 

Le mardi 20 mars 2018 17 h 42 min 47 s HAE, Pierre Béland 
<pierz...@yahoo.fr> a écrit :  
 
  Le 20/03/2018, Vincent de Château-Thierry a écrit :

> Une autre manière de voir (au sens propre) l'état de la couverture, 
> c'est via "Layers" : 
> http://layers.openstreetmap.fr/?zoom=7=47.27179=-72.20242=BFF
> Au moment du tracé des limites admin françaises c'était précieux, alors 
> pourquoi pas...

Merci, 
j'avais la mauvaise sélection, je n'avais que des suggestions d'ajout wikipedia 
aux relations.  Bon la première référence, le chemin sélectionné a plein de 
chevauchements. Je vais corriger le tout et voir si cela règle l'ensemble de 
mes problèmes.
 
Pierre 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Besoin d'aide pour Validation niveaux hiérarchiques Relations type=boundary

[Pierre Béland]

 Le 20/03/2018, Vincent de Château-Thierry a écrit :

> Une autre manière de voir (au sens propre) l'état de la couverture, 
> c'est via "Layers" : 
> http://layers.openstreetmap.fr/?zoom=7=47.27179=-72.20242=BFF
> Au moment du tracé des limites admin françaises c'était précieux, alors 
> pourquoi pas...

Merci, 
j'avais la mauvaise sélection, je n'avais que des suggestions d'ajout wikipedia 
aux relations.  Bon la première référence, le chemin sélectionné a plein de 
chevauchements. Je vais corriger le tout et voir si cela règle l'ensemble de 
mes problèmes.
 
Pierre 
  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Besoin d'aide pour Validation niveaux hiérarchiques Relations type=boundary

[Pierre Béland]

J'ai quelques soucis avec la validation de l'ajout de limites administratives 
de différents niveaux hiérarchique au Québec et l'expérience des contributeurs 
/ développeurs de OSM-France peut sûrement m'être utile. 

Plusieurs outils permettent de vérifier si un polygone est fermé (ie. éditeur 
de relation JOSM, Analyseur http://ra.osmsurround.org/analyzeRelation et 
couches de différents niveaux admin de Osmose).
Pour moi, la difficulté principale est la validation de la hiérarchie des 
relations admin pour un territoire donné, soit dans mon cas, le Québec.
On peut vérifier si un polygone de limite administrative est fermé à partir de 
l'éditeur de relations de JOSM ou avec 
http://ra.osmsurround.org/analyzeRelation.  Il est par contre plus difficile de 
valider la hiérarchie des polygones à l'intérieur d'un pays ou région donnée.

Pour la validation de la hiérarchie, je ne peux que constater avec les pages 
Admin de Nominatim si tous les sous-ensembles sont reconnus ou non.
Osmose propose les liens Analyse 1 et Analyse 2. Cependant, je n'ai pas trouvé 
de documentation la-dessuse et Analyse 1 ne reconnait pas les relations 
administratives du Québec - Est-ce que le Québec n'est pas couvert?
exemple http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=61549
analyse 2 me retourne simplement un ok + timestamp - Cela veut-dire relation ok?
polygons.openstreetmap.fr/~osmbin/analyse-relation-open.py?61549

La validation de la hiérarchie des limites admin ne semble pas traitée dans 
Osmose (à moins que analyse 1 joue ce rôle?). Si absent, ce serait un ajout 
intéressant. À ma connaissance, il n'existe pas d'autre outil. 
Autre piste, quelqu'un a un script python qui vérifie la hiérarchie des 
relations admin ?

Au Québec, les niveaux hiérarchiques de admin_level sont4 - Province de Québec5 
- Régions administratives (14)
6 - MRC (87)
8 - Municipalités.
Les pages Admin de Nominatim fournissent la liste des limites de niveau 
inférieur. Lorsqu'un polygone n'est pas listé, il est difficile d'identifier 
quel est le problème (ie. polygone non fermé, chevauchement, et parfois un 
simple tri des membres de relation peut donner un coup de pied et replacer le 
tout).

Pour le Québec, les régions administratives (admin_level=5) sont toutes 
reconnues par Nominatim, de même que les MRC (admin_level=6). Par contre, si je 
fait le tour des pages Admin niveau 5 (régions), la liste des MRC (niveau 6) 
est incomplète pour plusieurs régions, ce après moultes validations / 
corrections. Je me suis assuré avec JOSM que les polygones étaient clos et bien 
triés. J'ai aussi fait le contour des relations de niveau 5 pour m'assurer que 
les relations de niveau 6 étaient à l'intérieur ou sur la ligne outer du niveau 
5.

Voir par exemple avec Nominatim, la page Région Côte-Nord (admin_level=5). Une 
seule relation inférieure est affichée, la Minganie, et il en manque 5 autres.
https://nominatim.openstreetmap.org/details.php?place_id=230132861
Relations de niveau 6 non listées dans Cote-Nord
- Caniapiscau https://nominatim.openstreetmap.org/details.php?place_id=219756444
- La Haute-Côte-Nord 
https://nominatim.openstreetmap.org/details.php?place_id=219650807
- Le Golfe-du-Saint-Laurent 
https://nominatim.openstreetmap.org/details.php?place_id=220071937
- Manicouagan https://nominatim.openstreetmap.org/details.php?place_id=219650797
- Sept-Rivières 
https://nominatim.openstreetmap.org/details.php?place_id=219756445


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

Re: [Talk-ca] Cleanup of addr:country, addr:province, addr:state

[Pierre Béland]

J'ai ajouté short_name pour le Québec, mais je pense effectivement que c'est 
inutile à comparer avec Ontario. Dans ce cas, le ON fonctionne sans doute à 
cause de state_code=ON.
Et effectivement, lorsque les relations de territoires sont ajoutées et 
fonctionnelles, les is_in et addr:province sont inutiles et Nominatim fourni 
correctement l'info.  


 
Pierre 
 

Le lundi 19 mars 2018 11 h 18 min 23 s HAE, Matthew Darwin 
<matt...@mdarwin.ca> a écrit :  
 
  Searching on "110 Laurier Avenue West, on" in Nominatim already works (it 
finds Ottawa City hall) even though the address has no addr:province tag for 
City Halle.  So I don't think this is a good reason to be adding 
addr:province/addr:province:short_name tags. IMO.  Unless there is another use 
case I am missing.  Similarly your example of searching for "Toronto, ON" works 
fine.
 
 I'm guessing this works because the Ontario admin relation has ISO3166-2 tag 
of CA-ON
 
 
 


  On 2018-03-10 04:51 PM, Pierre Béland wrote:
 
   Non, inutile si relations. Dans relation province d'Ontario - ajouter 
short_name='ON'. 
  De cette façon, Recherche Toronto, ON
  devrait fonctionner. A essayer :)
  
   
 Pierre 
   
  
 Le samedi 10 mars 2018 15:39:53 HNE, john whelan <jwhelan0...@gmail.com> a 
écrit :  
  
  So you're suggesting adding short_name='ON' to ones that have 
addr:province=Ontario
 
  How would that work?
 
 addr:province=Ontario 
  addr:province:short_name=ON ?
 
  Merci John
   
   
 
   ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Cleanup of addr:country, addr:province, addr:state

[Pierre Béland]

J'ai fait recherche  «Toronto, On» Cela fonctionne. Peut-etre a cause de 
«state_code=ON»

 
Pierre 
 

Le samedi 10 mars 2018 15:39:53 HNE, john whelan <jwhelan0...@gmail.com> a 
écrit :  
 
 So you're suggesting adding short_name='ON' to ones that have 
addr:province=Ontario

How would that work?

addr:province=Ontario
addr:province:short_name=ON ?

Merci John

On 10 March 2018 at 15:27, Pierre Béland <pierz...@yahoo.fr> wrote:

John, on doit essayer d'être plus intuitif et permettre les deux façons de 
rechercher. Cela peut se faire simplement en ajoutant dans la relation province 
d'Ontario, short_name='ON'. 
Pour revenir aux suggestions de Matthew, de façon à impliquer / motiver les 
communautés locales, ce serait d'offrir les outils et listes d'objets à 
corriger un peu comme le fait Osmose et autres outils de QA.
 
Pierre 
 

Le samedi 10 mars 2018 13:53:35 HNE, john whelan <jwhelan0...@gmail.com> a 
écrit :  
 
 For Ontario I would suggest following the post office guidelines for province 
and using ON rather than a mixture of ON and Ontario.  That way it makes it 
easier to find an address since you just need to search for ON.  Currently you 
would need to search for both variations.
Cheerio John

On 8 Mar 2018 11:28 pm, "Matthew Darwin" <matt...@mdarwin.ca> wrote:


So I've tidied up the addr:province/state tags, now using only addr:province, 
leaving anything that would be generally considered "correct" either spelt out 
in full or using English provincial abbreviation as you might use in a mailing 
address. Also left "Quebec" (no accent).
I would rather like to clean this up further, however, I have stopped just at 
tidying up things that were mis-spelt or had inconsistent case.

Is there any view on where to go next?

These are the current counts:

69008   Nova Scotia
39668   ON
33280   British Columbia
 7788   Alberta
 6584   AB
 4771   BC
 4520   Québec
 3772   Ontario
 2791   QC
 2140   NB
 1744   SK
 1285   NU
 1066   NL
 1022   Manitoba
  879   New Brunswick
  527   Quebec
  307   PE
  234   NS
  222   MB
  163   Saskatchewan
   23   Nunavut
   14   NT
   11   YT
    9   Yukon
    3   Northwest Territories

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


__ _
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap. org/listinfo/talk-ca
  

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

Re: [Talk-ca] Cleanup of addr:country, addr:province, addr:state

[Pierre Béland]

Non, inutile si relations. Dans relation province d'Ontario- ajouter 
short_name='ON'.
De cette façon, Recherche Toronto, ON
devrait fonctionner. A essayer :)

 
Pierre 
 

Le samedi 10 mars 2018 15:39:53 HNE, john whelan <jwhelan0...@gmail.com> a 
écrit :  
 
 So you're suggesting adding short_name='ON' to ones that have 
addr:province=Ontario

How would that work?

addr:province=Ontario
addr:province:short_name=ON ?

Merci John

On 10 March 2018 at 15:27, Pierre Béland <pierz...@yahoo.fr> wrote:

John, on doit essayer d'être plus intuitif et permettre les deux façons de 
rechercher. Cela peut se faire simplement en ajoutant dans la relation province 
d'Ontario, short_name='ON'. 
Pour revenir aux suggestions de Matthew, de façon à impliquer / motiver les 
communautés locales, ce serait d'offrir les outils et listes d'objets à 
corriger un peu comme le fait Osmose et autres outils de QA.
 
Pierre 
 

Le samedi 10 mars 2018 13:53:35 HNE, john whelan <jwhelan0...@gmail.com> a 
écrit :  
 
 For Ontario I would suggest following the post office guidelines for province 
and using ON rather than a mixture of ON and Ontario.  That way it makes it 
easier to find an address since you just need to search for ON.  Currently you 
would need to search for both variations.
Cheerio John

On 8 Mar 2018 11:28 pm, "Matthew Darwin" <matt...@mdarwin.ca> wrote:


So I've tidied up the addr:province/state tags, now using only addr:province, 
leaving anything that would be generally considered "correct" either spelt out 
in full or using English provincial abbreviation as you might use in a mailing 
address. Also left "Quebec" (no accent).
I would rather like to clean this up further, however, I have stopped just at 
tidying up things that were mis-spelt or had inconsistent case.

Is there any view on where to go next?

These are the current counts:

69008   Nova Scotia
39668   ON
33280   British Columbia
 7788   Alberta
 6584   AB
 4771   BC
 4520   Québec
 3772   Ontario
 2791   QC
 2140   NB
 1744   SK
 1285   NU
 1066   NL
 1022   Manitoba
  879   New Brunswick
  527   Quebec
  307   PE
  234   NS
  222   MB
  163   Saskatchewan
   23   Nunavut
   14   NT
   11   YT
    9   Yukon
    3   Northwest Territories

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


__ _
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap. org/listinfo/talk-ca
  

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

Re: [Talk-ca] Cleanup of addr:country, addr:province, addr:state

[Pierre Béland]

John, on doit essayer d'être plus intuitif et permettre les deux façons de 
rechercher. Cela peut se faire simplement en ajoutant dans la relation province 
d'Ontario, short_name='ON'. 
Pour revenir aux suggestions de Matthew, de façon à impliquer / motiver les 
communautés locales, ce serait d'offrir les outils et listes d'objets à 
corriger un peu comme le fait Osmose et autres outils de QA.
 
Pierre 
 

Le samedi 10 mars 2018 13:53:35 HNE, john whelan  a 
écrit :  
 
 For Ontario I would suggest following the post office guidelines for province 
and using ON rather than a mixture of ON and Ontario.  That way it makes it 
easier to find an address since you just need to search for ON.  Currently you 
would need to search for both variations.
Cheerio John

On 8 Mar 2018 11:28 pm, "Matthew Darwin"  wrote:


So I've tidied up the addr:province/state tags, now using only addr:province, 
leaving anything that would be generally considered "correct" either spelt out 
in full or using English provincial abbreviation as you might use in a mailing 
address. Also left "Quebec" (no accent).
I would rather like to clean this up further, however, I have stopped just at 
tidying up things that were mis-spelt or had inconsistent case.

Is there any view on where to go next?

These are the current counts:

69008   Nova Scotia
39668   ON
33280   British Columbia
 7788   Alberta
 6584   AB
 4771   BC
 4520   Québec
 3772   Ontario
 2791   QC
 2140   NB
 1744   SK
 1285   NU
 1066   NL
 1022   Manitoba
  879   New Brunswick
  527   Quebec
  307   PE
  234   NS
  222   MB
  163   Saskatchewan
   23   Nunavut
   14   NT
   11   YT
    9   Yukon
    3   Northwest Territories

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


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

Re: [Talk-ca] Cleanup of addr:country, addr:province, addr:state

[Pierre Béland]

Matthew, 
Tu fais du travail très louable. En même temps, il est important pour certains 
éléments de connaitre le contexte local. Chaque province a ses règles au niveau 
des noms et il y a du ménage à faire. Par exemple, il y a eu un import massif 
de noms à partir de la base GNS. Ces données ne sont pas toujours de qualité.  
On y retrouve des codes inutiles. Par contre, cela aide à repérer ces éléments 
pour les traiter.  
Peut-être laisser cette responsabilité à chaque province. À noter aussi que les 
collaborateurs québécois ont leurs propres listes de discussion et sont peu 
présents sur cette liste.

 
Pierre 
 

Le jeudi 8 mars 2018 23:27:46 HNE, Matthew Darwin  a 
écrit :  
 
 
So I've tidied up the addr:province/state tags, now using only 
addr:province, leaving anything that would be generally considered 
"correct" either spelt out in full or using English provincial 
abbreviation as you might use in a mailing address. Also left "Quebec" 
(no accent).
I would rather like to clean this up further, however, I have stopped 
just at tidying up things that were mis-spelt or had inconsistent case.

Is there any view on where to go next?

These are the current counts:

69008   Nova Scotia
39668   ON
33280   British Columbia
  7788   Alberta
  6584   AB
  4771   BC
  4520   Québec
  3772   Ontario
  2791   QC
  2140   NB
  1744   SK
  1285   NU
  1066   NL
  1022   Manitoba
   879   New Brunswick
   527   Quebec
   307   PE
   234   NS
   222   MB
   163   Saskatchewan
    23   Nunavut
    14   NT
    11   YT
     9   Yukon
     3   Northwest Territories

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

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

[OSM-talk-fr] OSM-Pixels couteau suisse imagerie pour aider à l'édition OSM

[Pierre Béland]

Voici en quelque sorte mon petit couteau suisse pour rechercher un lieu et 
visualiser rapidement l'imagerie disponible et les modifications OSM réalisées. 
J'ai conçu OSM-Pixels (Openlayers v3+). Il fonctionne également avec les 
appareils mobiles.
https://pierzen.dev.openstreetmap.org/osm-pixels

On peut superposer une grille, les cartes vectorielles OpenInfraMap ou la 
couverture des images DigitalGlobe (date pour zoom élevés).
On retrouve quelques cartes OSM et les différentes images que l'on peut 
généralement utiliser pour tracer dans OSM.
Le bouton «Rechercher» en haut à gauche permet de rechercher un lieu.

Il est possible de voir le statut des tuiles ou de faire un dirty pour demander 
de rafraichir une tuile après édition. Nous avions discuté de cela l'an 
dernier. Voici une façon simple de le faire. Bouton gauche de la souris ou 
touche longue sur tablettes.

Pour ceux que les détails techniques intéressent :

On peut ajouter une grille avec les coordonnées x, y, z mais petit bug avec les 
versions récentes de Openlayers, la valeur Y est négative (fonction 
ol.tiledebug)  
Pierre 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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, 

Re: [Talk-ca] Meaning of lcn tag - designated route, or any cycling infrastructure

[Pierre Béland]

Bonjour Mike,
Voir la page wiki qui indique les trois niveaux de cette 
classificationhttps://wiki.openstreetmap.org/wiki/Cycle_routes
- icn international- lcn national- rcn régional
On y indique également  que les relations sont généralement mieux pour 
documenter un parcours. Voir une relation pour la Route verte au Québec avec 
des dizaines de membres pour la décrire. Et effectivement, on utilise cette 
classification pour des parcours reconnus soit au niveau régional ou national.

https://www.openstreetmap.org/relation/416115
 
Pierre 
 

Le dimanche 4 février 2018 14:39:50 HNE, Mike Boos  a 
écrit :  
 
 Hello
I've noticed some users have begun tagging some roads in a number of Canadian 
cities with lcn=yes tags, which are intended for marking local cycling routes. 
My understanding of the lcn tag was that it was intended for marking designated 
routes, not just any old way that is potentially bikeable or personal 
preferences cycling routes. 
For many roads, the lcn tag seems redundant, since these ways are already 
tagged with cycleway=lane or something similar, and there is no accompanying 
lcn_ref tag to provide information on individual route names or numbers (if 
they exist). Other roads have been tagged, but have no infrastructure or 
signage, which suggests someone is simply marking their personal routes. 
I'd like to think I have some sort of expertise in what constitutes an official 
local cycling route in my area, having served as a member and later chair of 
the Kitchener Cycling and Trails Advisory Committee for several years. There 
are some signed routes that myself and others in the area have properly marked 
with relations. But is my understanding of what the lcn tag is for wrong? I'd 
like to know before I start cleaning things up.
ThanksMike
-- 
Mike Boos, MASc.
mike.boos@gmail.com___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] using image recognition to create building foot prints.

[Pierre Béland]

Pierre, 
Je suis aussi intéressé à collaborer à tester de telles données  Les milieux 
urbains denses devraient poser un problème particulier pour l'identification 
des immeubles individuels. À voir comment les modèles de classification peuvent 
performer en utilisant les données d'élévation.
 
Pierre 
 

Le vendredi 2 février 2018 11:10:41 HNE, john whelan 
<jwhelan0...@gmail.com> a écrit :  
 
 I think when you have something available we should be able to find resources 
to double check the quality and also to work out a process to import them.  The 
latter will be interesting both from the technical point of view and the 
acceptance within the OSM community. 

My concern on the Canadian building project was getting reasonable building 
outlines from a mixture of mappers given some experiences we've seen in the 
past. 

Cheerio John

2018-02-02 11:01 GMT-05:00 Gravel, Pierre (NRCan/RNCan) 
<pierre.gra...@canada.ca>:


Hi John, yes I am on the mailing list.

I confirm that we (NRCAN) are working on a process to extract building 
footprints from airborne LiDAR data and we expect to disseminate these 
footprints from June 2018 on Open Map Canada Portal.

The accuracy of these footprints well be very good, but of course that an 
automatic extraction process can’t be better than human eyes.

The quality of these footprints are totally depending on the quality of the 
LiDAR data in input (density and classification) and we will filter LiDAR 
projects that we will use to make sure that the footprints quality will meet a 
minimum threshold.

It’s not an objective of NRCAN to upload these footprints on OSM, but I think 
that these footprints can be a very good start for OSM communities then to 
allow people to improve these footprints.

I take the opportunity to ask you if you accept to give us a feedback on these 
footprints before the official launch.

If yes, It will be my pleasure to provide a pre-production data for those who 
want to check them.

 

It sounds good ?

 

Best Regards

 

Pierre Gravel

Centre canadien de cartographie et d’observation de la terre

Ressources naturelles Canada / Gouvernement du Canada

pierre.gra...@canada.ca / Tél. 819-564-5600, poste 246

 

Canadian Center of Mapping and Earth Observation

Natural Resources Canada / Government of Canada

pierre.gra...@canada.ca / Tel. 819-564-5600, x246

 

 

 

 

From: Pierre Béland [mailto:pierz...@yahoo.fr]
Sent: January 29, 2018 4:54 PM
To: Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>; john whelan 
<jwhelan0...@gmail.com>
Cc: Gravel, Pierre (NRCan/RNCan) <pierre.gra...@canada.ca>
Subject: Re: [Talk-ca] using image recognition to create building foot prints.

 

Précision,  

Les missions aériennes permettent de produire des images de grande qualité. 

 On y associe des équipements LIDAR qui émettent un signal vers le sol pour 
mesurer la distance. Aussi bien la technique LIDAR que de petits drones sont 
aujourd'hui capables de produire des modèles d'élévation avec quelques 
centimètres de précision.  Cela permet aussi de produire des modèles 3D des 
immeubles et de distinguer avec la végétation.

 

Suite aux inondations du Richelieu et du Lac Champlain en 2011, des modèles 
d'élévation très des zones urbaines en bordure de la rivière Richelieu ont été 
produites.

 

Si on se rappelle les discussions il y a quelques mois, un tel travail d'import 
va nécessiter des ressources importantes. Les diverses communautés OSM locales 
devront évaluer leur capacité à réaliser des projets d'import d'immeubles. Et 
il faut éviter de se baser sur le modèle «Cartoparties» pour réaliser de tels 
projets. Des milliers de personnes qui sont sensibiliées quelques heures à la 
cartographie ne reviennent pas ensuite et laisse souvent une donnée de piètre 
qualité.

 

Il faut être réaliste et construire peu à peu, motiver des communautés locales 
à expérimenter un modèle d'import de la donnée. Cela fera ensuite boule de 
neige ( c'est de saison :)  )


Pierre

 

 

Le lundi 29 janvier 2018 16:07:31 HNE, Pierre Béland <pierz...@yahoo.fr> a 
écrit :

 

 

Bonjour John

 

Les spécialistes d'imagerie produisent des couches de données assez précises à 
partir d'imagerie LIDAR ou de drones, incluant, immeubles, cours d'eau et 
occupation du sol. Ces images offrent qualité et précision. Des techniques de 
classification, interprétation, correction permettent aux spécialistes de 
converger vers un produit de qualité.  Et bien sûr toutes ces avancées 
technologiques et l'accès éventuel à des profanes bousculent les habitudes tout 
comme les véhicules sans conducteur :)

 

Même si Statistique Canada fournit à OSM un fichier produit par des 
spécialistes, il sera nécessaire ensuite d'établir une procédure d'import, de 
fusionner / aligner avec les données existantes et de corriger. 

 

Et ouvront la porte au Futur! Une autre avenue, c'est l'accès aux profanes que 
nous sommes à des outils semi-automatiques

Re: [Talk-ca] Buildings in Montreal

[Pierre Béland]

La série Carte de base contient sans doute les données du cadastre(format 
Autocad échelle 1/1,000). 
http://donnees.ville.montreal.qc.ca/dataset/cartographie-de-base
Les contributeurs de Montréal sont en lien avec la ville de Montréal et peuvent 
sans doute obtenir des extractions sous d'autres formats. Ils ont leur propre 
site internet et Liste de discussion.  
voir http://www.openstreetmap-montreal.org/
http://listes.osmqc.ca/
 
Pierre 
 

Le mardi 30 janvier 2018 08:39:57 HNE, James  a écrit 
:  
 
 sorry, they do have buildings. but its combined with a bunch of other 
things in DWG format called "Cartographie de base"
On Jan 30, 2018 8:34 AM, "James"  wrote:

they seem to only have addresses and lidar.
On Jan 30, 2018 8:30 AM, "john whelan"  wrote:

But do they have a buildings outline file?
Thanks John
On 30 Jan 2018 7:52 am, "James"  wrote:

I was looking at license on the montreal site and they even say for OSM to use 
their data:
http://donnees.ville.montreal. qc.ca/portail/license/(scroll down)
On Jan 30, 2018 6:57 AM, "john whelan"  wrote:

Since Montreal would appear to have an acceptable licence and Open Data does it 
have a building outline file that technically could be imported?
The second part would be does it have local mappers who would be willing to 
support such an import?
On the more technical side I would imagine it would need to be done in sections 
and I'm unsure how many buildings are already mapped.  The more there are the 
more complex the import would be.
Thanks John
__ _
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.or g/listinfo/talk-ca






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

Re: [Talk-ca] using image recognition to create building foot prints.

[Pierre Béland]

Effectivement, on en revient aux discussions d'il y a quelques mois. Nous avons 
indiqué dès le départ que ce projet était très ambitieux et qu'il y avait des 
risques importants sur la qualité de la données si on s'appuyait principalement 
sur des groupes inexpérimentés via les universités, etc. 
John mentionnait la réponse pour le Népal. Nous venions de terminer la réponse 
pour l'Ébola après près d'un an de cartographie intensive.  Nous avions 
plusieurs défis à surmonter avec l'absence d'imagerie récente, des communautés 
isolées en montagne, des communications interrompues.  A cela s'est ajoutée la 
vague déferlante des carto-parties. Les médias avaient beaucoup parlé de la 
réponse humanitaire OSM aux diverses crises humanitaires. Beaucoup de groupes 
étaient intéressés à collaborer. Encore plus que pour Tacloban aux Philippines 
et pour l'Ebola.  Les statistiques montraient des records de participation de 
nouveaux contributeurs. En contrepartie, John et d'autres qui validaient les 
données, rapportaient continuellement des problèmes de qualité de la donnée. 
Nous avons vécu le même problème avec Haiti en octobre 2016. 

Il faut une part de réalisme. Pour bien coordonner, il ne suffit pas de créer 
une tâche et d'inviter à participer. Nous ne sommes pas une communauté 
structurée au niveau national.  Je comprends que diverses universités 
s'intéressent au projet OSM et aimeraient initier leurs étudiants à ce projet. 
La meilleure solution je pense c'est de se mettre en contact avec la communauté 
OSM locale et s'assurer de bien encadrer la formation et les premiers jours de 
participation à OSM.

Les contributeurs sont davantage actifs dans leurs communautés locales ou selon 
leur divers intérêts liés à leur travail ou loisir. Personne n'est prêt à 
s'engager à coordonner un tel projet au niveau national.  
Des personnes comme John et moi avons consacré beaucoup de temps à coordonner, 
supporter les réponses humanitaires OSM au niveau international. Nos propos 
prudents visent à en venir à une approche réaliste.  Il vaut mieux partir sur 
des bases solides, initier quelques projets au départ si des communautés sont 
prêtes à les supporter.    
Pierre 
 

Le lundi 29 janvier 2018 18:57:14 HNE, john whelan  
a écrit :  
 
 ​The idea behind the building project is good.  Basically you need a mixture 
of accurate building outlines and tags.  From there the statisticians can work 
their magic.  This is true in Canada as well as other parts of the world.  With 
OSM buildings and tags combined with open source stats software R (R.org) you 
get ground floor GIS planning tools and they are badly needed in Africa etc.  
If we can pull it off this is good.

First Pierre's point that machine learning and imagery is a little different to 
using radar type technology. If we would have had it available in Nepal it 
would have saved a lot of problems.  Even today in Africa the standard of 
building mapping would be much improved by the use of such technology.

It isn't yet accepted by OSM as mainstream.  That is an issue we need to get 
round before we can use the stuff.

However Canada has always been in the forefront of imports.  We have a history 
of using NCR Canada’s data ie CANVEC and we are comfortable using it.  Some 
parts we recognise are better quality than others.  We also have within the 
mailing list some deep technical expertise which can be used to evaluate the 
radar type technology for detecting building outlines.  I think it will take 
time to get this technology accepted by OSM and that is the point of this 
thread.

I think we have to accept that the BC2020i project is one that was not dreamt 
up by the OSM community.  I think the idea came out of Alessandro of Stats 
Canada and my understanding is the web page was put together by a single person 
with little experience of OSM, the processes and politics involved. There is 
demand for the data but OSM is more geared towards mappers than customer 
demands.

What we have ended up with is a project with lots of words and aspirations but 
little apparent understanding of what is involved.  The idea has been picked up 
by High Schools and Universities and we are now getting inexperienced mappers 
in with little training adding buildings to the map in iD and the data quality 
is poor for some and that is an issue since it reflects on the project itself.

There seems to be no project manager and that is an issue.  We’ve cleaned up 
the wiki page to some extent.  There is a demand from schools and Universities 
to get involved.  We need someone to put together guidance for these people.

I take Pierre’s point that in an ideal world experienced local mappers would 
map locally and take responsibility for their area importing when appropriate.  
Unfortunately we do not live in an ideal world.

Cheerio John​

On 29 January 2018 at 17:59, OSM Volunteer stevea  
wrote:

On Jan 29, 2018, at 2:35 PM, 

Re: [Talk-ca] using image recognition to create building foot prints.

[Pierre Béland]

Précision,   Les missions aériennes permettent de produire des images de grande 
qualité.  On y associe des équipements LIDAR qui émettent un signal vers le sol 
pour mesurer la distance. Aussi bien la technique LIDAR que de petits drones 
sont aujourd'hui capables de produire des modèles d'élévation avec quelques 
centimètres de précision.  Cela permet aussi de produire des modèles 3D des 
immeubles et de distinguer avec la végétation.
Suite aux inondations du Richelieu et du Lac Champlain en 2011, des modèles 
d'élévation très des zones urbaines en bordure de la rivière Richelieu ont été 
produites. Si on se rappelle les discussions il y a quelques mois, un tel 
travail d'import va nécessiter des ressources importantes. Les diverses 
communautés OSM locales devront évaluer leur capacité à réaliser des projets 
d'import d'immeubles. Et il faut éviter de se baser sur le modèle 
«Cartoparties» pour réaliser de tels projets. Des milliers de personnes qui 
sont sensibiliées quelques heures à la cartographie ne reviennent pas ensuite 
et laisse souvent une donnée de piètre qualité.
Il faut être réaliste et construire peu à peu, motiver des communautés locales 
à expérimenter un modèle d'import de la donnée. Cela fera ensuite boule de 
neige ( c'est de saison :)  )

Pierre 
 

Le lundi 29 janvier 2018 16:07:31 HNE, Pierre Béland <pierz...@yahoo.fr> a 
écrit :  
 
 Bonjour John
Les spécialistes d'imagerie produisent des couches de données assez précises à 
partir d'imagerie LIDAR ou de drones, incluant, immeubles, cours d'eau et 
occupation du sol. Ces images offrent qualité et précision. Des techniques de 
classification, interprétation, correction permettent aux spécialistes de 
converger vers un produit de qualité.  Et bien sûr toutes ces avancées 
technologiques et l'accès éventuel à des profanes bousculent les habitudes tout 
comme les véhicules sans conducteur :)
Même si Statistique Canada fournit à OSM un fichier produit par des 
spécialistes, il sera nécessaire ensuite d'établir une procédure d'import, de 
fusionner / aligner avec les données existantes et de corriger. 
Et ouvront la porte au Futur! Une autre avenue, c'est l'accès aux profanes que 
nous sommes à des outils semi-automatiques pour faciliter la digitalisation de 
différents éléments tels immeubles, routes et rivières. Je ne connais pas 
l'historique des expériences d'utilisation de tels outils. Mais on peut 
remonter en 2011, où on parlait d'un outil de détection de route. Divers 
articles traitent aussi de ce sujet.
https://alastaira.wordpress.com/2011/02/04/automatic-road-detection-using-bing-maps-imagery/https://gis.stackexchange.com/questions/77876/is-there-a-tool-that-performs-automatic-recognition-of-buildings


Facebook a aussi expérimenté des outils de reconnaissance d'image en Thaîlande 
récemment. Selon les plaintes de certains contributeurs, les données ont été 
ajoutées à OSM sans valider suffisamment avec la réalité sur le terrain.
Je pense qu'il serait intéressant pour les contributeurs expérimentés d'avoir 
accès à des outils semi-automatisés facilitant dans JOSM par exemple le tracé 
d'immeubles, routes, cours d'eau, etc. Pour un cours d'eau par exemple, je 
déplace le curseur de la souris, et les contours et le centre de la rivière 
sont tracés automatiquement. Ou encore le contour d'un lac est tracé.
 
Pierre 
 

Le lundi 29 janvier 2018 15:15:59 HNE, john whelan <jwhelan0...@gmail.com> 
a écrit :  
 
 ·    NRCan is working on a methodology to extract building  footprints, 
including topographic elevation and height attributes, from LiDAR


Traditionally OSM has not been happy with this sort of thing.  The accuracy can 
be poor.

We probably need to think about this since the BC2020i project had this 
mentioned and Stats Can has given it a mention also.  I'm not promoting it nor 
saying its bad but it will almost certainly be raised shortly.

First if an import was done using this data who would be the local group to 
approve it?  I suspect because it covers the entire country it would be the 
talk-ca group.  The date would come through the TB portal so licensing is not 
an issue.  Or it could be split into regions with regional local groups making 
decisions.

The other very big question is to do with data quality.  So far nothing that is 
machine learnt from imagery has consistently met the expectations of 
OpenStreetMap.

Note to Pierre I'm not sure if you are on the talk-ca mailing list but any 
feedback you might have on the data quality side would be welcome and will be 
shared amongst the group.

Thoughts?

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

Re: [Talk-ca] using image recognition to create building foot prints.

[Pierre Béland]

Bonjour John
Les spécialistes d'imagerie produisent des couches de données assez précises à 
partir d'imagerie LIDAR ou de drones, incluant, immeubles, cours d'eau et 
occupation du sol. Ces images offrent qualité et précision. Des techniques de 
classification, interprétation, correction permettent aux spécialistes de 
converger vers un produit de qualité.  Et bien sûr toutes ces avancées 
technologiques et l'accès éventuel à des profanes bousculent les habitudes tout 
comme les véhicules sans conducteur :)
Même si Statistique Canada fournit à OSM un fichier produit par des 
spécialistes, il sera nécessaire ensuite d'établir une procédure d'import, de 
fusionner / aligner avec les données existantes et de corriger. 
Et ouvront la porte au Futur! Une autre avenue, c'est l'accès aux profanes que 
nous sommes à des outils semi-automatiques pour faciliter la digitalisation de 
différents éléments tels immeubles, routes et rivières. Je ne connais pas 
l'historique des expériences d'utilisation de tels outils. Mais on peut 
remonter en 2011, où on parlait d'un outil de détection de route. Divers 
articles traitent aussi de ce sujet.
https://alastaira.wordpress.com/2011/02/04/automatic-road-detection-using-bing-maps-imagery/https://gis.stackexchange.com/questions/77876/is-there-a-tool-that-performs-automatic-recognition-of-buildings


Facebook a aussi expérimenté des outils de reconnaissance d'image en Thaîlande 
récemment. Selon les plaintes de certains contributeurs, les données ont été 
ajoutées à OSM sans valider suffisamment avec la réalité sur le terrain.
Je pense qu'il serait intéressant pour les contributeurs expérimentés d'avoir 
accès à des outils semi-automatisés facilitant dans JOSM par exemple le tracé 
d'immeubles, routes, cours d'eau, etc. Pour un cours d'eau par exemple, je 
déplace le curseur de la souris, et les contours et le centre de la rivière 
sont tracés automatiquement. Ou encore le contour d'un lac est tracé.
 
Pierre 
 

Le lundi 29 janvier 2018 15:15:59 HNE, john whelan  
a écrit :  
 
 ·    NRCan is working on a methodology to extract building  footprints, 
including topographic elevation and height attributes, from LiDAR


Traditionally OSM has not been happy with this sort of thing.  The accuracy can 
be poor.

We probably need to think about this since the BC2020i project had this 
mentioned and Stats Can has given it a mention also.  I'm not promoting it nor 
saying its bad but it will almost certainly be raised shortly.

First if an import was done using this data who would be the local group to 
approve it?  I suspect because it covers the entire country it would be the 
talk-ca group.  The date would come through the TB portal so licensing is not 
an issue.  Or it could be split into regions with regional local groups making 
decisions.

The other very big question is to do with data quality.  So far nothing that is 
machine learnt from imagery has consistently met the expectations of 
OpenStreetMap.

Note to Pierre I'm not sure if you are on the talk-ca mailing list but any 
feedback you might have on the data quality side would be welcome and will be 
shared amongst the group.

Thoughts?

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

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 <mmd@gmail.com> 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=8.3169=Mapnik=T=0%2C8300=1%2C2==
>    
>
>
>    Or addressee the class 2 only.
>    http://osmose.openstreetmap.fr/en/map/#item=0=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 
<miketh...@gmail.com> 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 <pierz...@yahoo.fr> 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 
<miketh...@gmail.com> a écrit :  
 
 On Fri, Nov 24, 2017 at 3:43 PM, john whelan <jwhelan0...@gmail.com>  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