Re: [Talk-ca] Multipolygon problems

[Stewart C. Russell]

On 2017-07-01 05:22 PM, Jochen Topf wrote:
> 
> There is nothing specific about woods here.

It seems, though, that the root problem in Canada is *mostly* related to
woods imported from Canvec. And we have some very large forestry
relations indeed. I was finding that the JOSM process was using 13 GB of
RAM just to load one.

> Of course you should still check all cases against sat images.

Outside cities, sat images are extremely poor in Canada. You might get
10 year old 7½-metre greyscale images. Which if you're looking at a
logging/bark beetle area could be way off current reality.

 Stewart

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

Re: [Talk-ca] Multipolygon problems

[James]

Depends where you get the data I think, canvec from ftp is different from
canvec from toporama/atlas

On Jul 1, 2017 5:44 PM, "Stewart C. Russell"  wrote:

> Hi James,
>
> > Canvec 10.0 doesnt have the issues of double tagging, just overlapping
>
> I've found a whole bunch of Canvec 10 data with this problem west of
> Sudbury. I think it may still be an issue with later versions.
>
>  Stewart
>
> ___
> 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] Multipolygon problems

[Stewart C. Russell]

Hi James,

> Canvec 10.0 doesnt have the issues of double tagging, just overlapping

I've found a whole bunch of Canvec 10 data with this problem west of
Sudbury. I think it may still be an issue with later versions.

 Stewart

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

Re: [Talk-ca] Multipolygon problems

[Jochen Topf]

On Sat, Jul 01, 2017 at 04:04:25PM -0400, Stewart C. Russell wrote:
> On 2017-07-01 04:30 AM, Frank Steggink wrote:
> > 
> > To all, this is the procedure I used yesterday, and probably something
> > similar also by Pierre.
> > * Not sure if it is a requirement, but it's better to use 64 bit Java.
> > …
> 
> Thanks for this, Frank. I think I've found a way to make this a bit
> quicker by loading a relation URL, then using your search query:
> 
> > * Eventually JOSM starts looking cluttered, because of all the extra
> > data. You can use the search query "type:way natural=wood role:outer" to
> > see if there are still rings needing work.
> 
> … then just deleting the ‘natural=wood’ from the selected ways.
> 
> I hope I'm understanding the problem correctly*: outer ways in a forest
> polygon relationship shouldn't have the ‘natural=wood’ tag? If that's
> the issue, then this should just be an auto-edit, no JOSM and
> pointy-clicky required.

There is nothing specific about woods here. An outer way in a
multipolygon relations should only have tags which apply to *that way*
specifically, not tags which apply to the whole relation. The tags on
the relation are for the polygon as a whole, the tags on the ways are
for those ways.

So if you have, say a wall surrounding a forest, you might have tags for
that wall on the ways, but the forest tags belong on the multipolygon
relation only. In most cases this simply means that there should be no
tags on the ways at all.

Of course you should still check all cases against sat images. For
instance, sometimes the whole relation can be removed and just a simple
closed way be used if there are no inner ways.

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

hebdoOSM Nº 362 2017-06-20-2017-06-26

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 362 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/9199/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

hebdoOSM Nº 362 2017-06-20-2017-06-26

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 362 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/9199/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

hebdoOSM Nº 362 2017-06-20-2017-06-26

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 362 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/9199/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [OSM-talk-fr] Mapillary : photos basse résolution

[Eric SIBERT]

Je n'envoie pas les photos avec l'appli mais je les transfère sur mon PC où je
les traite avant de les envoyer [...]. Le traitement, je le fais surtout pour 
améliorer la géolocalisation des
photos avec le tracé GPS de mon Garmin qui est meilleur que le GPS de mon
téléphone. Je le fais dans JOSM et j'en profite pour supprimer les images de
mauvaise qualité ou redondantes.


Aujourd'hui, j'ai fait un essai. J'ai enregistré un trace GPX avec mon 
Etrex en même temps que les captures de Mapillary. De retour à la 
maison, je transfère les photos sur mon PC. J'utilise Geosetter pour les 
géoréférencer... et c'est super mieux que le smartphone. Et ensuite?


Je remets les photos géoréférencées dans le téléphone et je les envoie 
chez Mapillary avec leur logiciel. Les photos finissent en ligne avec le 
géoréférencement pourri du smartphone.


Depuis le PC, je passe par le site web de Mapillary pour envoyer 
directement les photos. Elles sont bien géoréférencées mais toutes 
orientées plein nord.


Je fais comment pour avoir bon géoréférencement et bonne orientation?

À noter qu'il ne semble pas y avoir d'orientation dans les fichiers 
exifs sortant du smartphone, pas d'orientation dans le fichier gpx 
enregistré par Mapillary donc je suppose l'orientation est déduite des 
déplacements. D'ailleurs les photos prises en train sont orientées dans 
le sens de la marche même quand elles sont manifestement prises de travers.


Eric

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

Re: [Talk-ca] Multipolygon problems

[Stewart C. Russell]

On 2017-07-01 04:30 AM, Frank Steggink wrote:
> 
> To all, this is the procedure I used yesterday, and probably something
> similar also by Pierre.
> * Not sure if it is a requirement, but it's better to use 64 bit Java.
> …

Thanks for this, Frank. I think I've found a way to make this a bit
quicker by loading a relation URL, then using your search query:

> * Eventually JOSM starts looking cluttered, because of all the extra
> data. You can use the search query "type:way natural=wood role:outer" to
> see if there are still rings needing work.

… then just deleting the ‘natural=wood’ from the selected ways.

I hope I'm understanding the problem correctly*: outer ways in a forest
polygon relationship shouldn't have the ‘natural=wood’ tag? If that's
the issue, then this should just be an auto-edit, no JOSM and
pointy-clicky required.

cheers,
 Stewart

*: here's one of my edits, just in case I'm doing it wrong:
https://www.openstreetmap.org/changeset/49971662

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

Re: [OSM-talk-fr] repérage géolocalisé sur le terrain

[osm . sanspourriel]

Le 01/07/2017 à 12:09, marc marc - marc_marc_...@hotmail.com a écrit :

  > Osmand affiche aussi un cercle dont le rayon représente
  > cette incertitude.
J'ai fais hier un peu plus attention au cercle dans Go Map!
On voit clairement 2 effets différents :
L'imprécision bien connue au démarrage où le cercle est grand.
Mais quand la localisation fait des bonds, le cercle reste étroit,
la position réelle est alors très fortement hors du cercle.

Et dans OSMAND ?

OSMTracker qui permet d'enregistrer le trajet avec la précision horizontale 
(qui est d'ailleurs affichée).

Je vais le tester. Mais ensuite comment utilise-t-on cette info ?

Avec ses yeux ;-)

Il existe un outil pour faire ressortir les photos correspondant à un
moment oü le HDOP est mauvais ?

Je suppose qu'avec QQIS tu peux analyser le GPX.

  OSMTracker lui même permet-il de générer
une alerte visuelle ou sonore ?
Car au final, à pied, quand le signal est mauvais, la meilleur solution
est souvent d'attendre quelques secondes avant de prendre la photo.
C'est pour ça que je disais avec les yeux : tu surveilles la distance 
indiquée et si ça déconne tu te mets dans un coin et tu attends que ça 
lui passe.
Je n'ai pas trouvé d'appli toute faite notifiant en cas de perte de 
précision du GPS. Pourtant les interfaces d'Android permettent d'accéder 
facilement à l'information.
J'aime assez SatStat (que tu trouves sur Fdroid) pour la clarté et la 
précision des infos sur la constellation (et sur d'autres capteurs comme 
l'accélération, l'orientation, l'inclinaison) : tu trouveras peut-être 
que c'est quand l'inclinaison est dans une plage que tu as moins de 
précision.
De plus SatStat te permet de télécharger les infos AGPS qui doivent te 
permettre d'acquérir un fix plus vite.
Peut-être que HUD (toujours sur Fdroid) en t'indiquant une absence de 
mise à jour en 2,5 s fera ton bonheur. Interface minimaliste !


Au fait, il est possible que Mapillary utilise d'autres capteurs pour 
estimer la position entre deux fix.
C'est ce que fait SmartNavi, là en utilisant parcimonieusement le GPS et 
les autres capteurs pour les positions intermédiaires.

Je partage tout à fait ton avis sur la cohérence matériel-logiciel-donnée.
Mais fait-tu si souvent de l'enregistrement de trace au point de
justifier un appareil dédié ?
Moi non, je disais ça pour Christian et Stéphane, toi peut-être (ça tu 
arrives à la précision décimétrique/centimétrique mais il y a la 
question du coût et de la consommation en énergie - faible mais en plus 
de celle du téléphone).

  > (plus durcie que le Rapsberry)
que veux-tu dire ? une meilleur résistance mécanique/électrique ?
Oui : composants acceptant une plus large de gamme de température. Le 
Rapsberry est prévu pour une utilisation en intérieur et avec pour but 
le prix le plus bas. Côté mécanique, c'est surtout le boîtier qui 
compte. Quelques Euros pour un plastique pas étanche, dix fois plus pour 
un boîtier alu.

En passant, existe-t-il des appareils (financièrement accessible) avec
DGPS, EGNOS ou équivalent ? quelle précision en obtient-on ?
C'est pour cela que je parlais de RTKLib. DGPS, tu oublies, vieux et 
inefficace par rapport à RTKLib.
RTKLib utilise le fait que le signal brut avant conversion en numérique 
est plus riche et permet d'avoir cette précision différentielle.

La précision relative est centimétrique.
Un BBB c'est 50 € environ. Un GPS supportant le mode brut, c'est aussi 
50 €. Tu ajoutes une antenne, une batterie.

Après ça rentre dans ton budget ou pas.
Voir le wiki : http://wiki.openstreetmap.org/wiki/RTKLIB.
Toujours sur Fdroid, tu peux utiliser RTKGps.

Le sujet a déjà été évoqué sur la liste :
Sujet : [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib
Date :  Mon, 08 Feb 2016 22:14:59 +0100
De :Jean-Michel Pouré
Pour :  Discussions sur OSM en français 

et Stéphane a fait un atelier sur le sujet à State Of The Map à 
Clermont-Ferrand


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

Re: [Talk-ca] Radio-Canada - Carte Google premières nations est la meilleure - Réagissez

[Pierre Béland]

Suite aux discussions de cette semaine et à partir de la liste wikipedia, la 
Carte des établisements autochtones est complétée pour le territoire du Québec. 
Améliorations possibles bien sûr.
Following this week discussions and from the wikipedia list, the Map of 
indigenous establishment is completed for the Quebec territory. There are 
surely some possible enhancements.

Carte Overpass
http://overpass-turbo.eu/s/q6v  
Pierre 

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

Re: [OSRM-talk] Example of restricted access flags for way_function and turn_function

[Mateusz Loskot]

Daniel,

Thanks for the pointers. I'll check them in details.

So, I understand purpose of turn_function is to tweak penalty based on
restrictions.

I'm wondering about slightly different use case and I'm trying to
understand which
tool, way_function or turn_function or neither, is the right way to use.
Shortly, in my use case a restriction is related to allowed/disallowed
turn from one link to another.
Let's consider simple network.

C
|
B---A
|
D

Let's assume, all links are bidirectional ways.
Node B includes information about turn restriction like so:
- turning from AB link to BD link is disallowed
- turning from AB link to CB link is allowed

AFAIU, object in turn_function has no context related to B node and
adjecent links to,
eg. calculate artificial high penalty to effectively block AB to BD turn
I'm also not sure there is way to include necessary context details in
object passed to way_function.

But, perhaps I'm missing some advanced profile tricks here.
So, does processing of such restrictions fit purpose of turn_function at all?

One of feasible alternative approaches is to pre-process such network
splitting the B node to B and B-prim

A - B - C
C - B' - D

This would effectively disable travelling along A - B - D

I'll appreciate any comments.

Best regards,
Mateusz




On 1 July 2017 at 10:41, Daniel Hofmann  wrote:
> You are correct, the way function can set a "restricted" flag per way (and
> direction), which you can then use in the turn function to put a high
> penalty on turns from/to "restricted" ways.
>
> The general idea is outlined here:
>
> https://www.openstreetmap.org/user/happygo/diary/40564
>
> Have a look at ExtractionWay, ExtractionTurn and the EdgeBasedGraphFactory.
>
> Cheers,
> Daniel J H
>
> On Sat, Jul 1, 2017 at 12:08 AM, Mateusz Loskot  wrote:
>>
>> Hi,
>>
>> I'm trying to learn about use of the way_function result flags,
>> forward_restricted and backward_restricted, and their correspondence
>> with turn_function machinery, especially input source_restricted and
>> target_restricted flags.
>>
>> Is there any data and profile example which shoes these in action?
>>
>> I guess, way_function is called first and any of the restriction flags set
>> here for the link are passed to turn_function. Correct?
>>
>> Disclaimer: I haven't looked into OSRM implementation details yet,
>> which, once grasped, I guess, might be enlightening.
>>
>> Best regards,
>> --
>> Mateusz Loskot, http://mateusz.loskot.net


-- 
Mateusz Loskot, http://mateusz.loskot.net

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

Re: [Talk-ca] Multipolygon problems

[Pierre Béland]

Merci à vous deux. Pour ce qui est de Jochen, je l'invite à descendre au niveau 
des paqueretes et apprendre le respect, la communication plus positive ;)
La requête Overpass peut être utilisée directement dans JOSMFichier / 
Téléchargement depuis Overpass-API
 
Pierre 


  De : James 
 À : Frank Steggink  
Cc : Talk-CA OpenStreetMap 
 Envoyé le : samedi 1 juillet 2017 8h25
 Objet : Re: [Talk-ca] Multipolygon problems
   
Error free Québec, just in time for Canada day! Good job Pierre :-)
On Jul 1, 2017 4:34 AM, "Frank Steggink"  wrote:

Hi Jochen,

Maybe a MapRoulette challenge might even not be necessary. Yesterday I started 
to clean up a bit in Québec, but since it was already past midnight for me, I 
wanted to continue this morning. To my surprise Pierre has done a lot of work 
and now the entire province of Québec looks to be free from these errors. I 
just could find three errors, and fixed them. Bon travail, Pierre!

The OSM inspector will still be a good idea, in order to spot future errors.

To all, this is the procedure I used yesterday, and probably something similar 
also by Pierre.
* Not sure if it is a requirement, but it's better to use 64 bit Java.
* You'll need JOSM with the remote control plugin. You'll also need to start 
JOSM.
* Use Pierre's Overpass query (http://overpass-turbo.eu/s/q5 K), and zoom/pan 
to the area of interest.
* Press Run and let Overpass do its work. Don't be afraid when Overpass 
mentions that the result is huge if you have a modern computer. Last night I 
wasn't experiencing any problems with 30MB data.
* Press Export, and choose JOSM. Press "Repair query" when Overpass asks you to 
decide.
* JOSM starts downloading the data. Note that you're only getting the outer 
rings.
* Go to these rings one by one, and load data (at least you'll need the 
relationship itself).
* Remove the natural=wood tag from the outer ring.
* Eventually JOSM starts looking cluttered, because of all the extra data. You 
can use the search query "type:way natural=wood role:outer" to see if there are 
still rings needing work.
* Upload your changes. Be prepared to handle conflicts if someone else is 
working near you on this issue as well.
* After a while, check Overpass Turbo again.

I'm not sure what the update frequency is, but Pierre's changes from 4 hours 
ago were already processed.

Good luck!

Frank


On 01-07-2017 09:52, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote:

On 30-06-2017 21:21, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:

Maybe I'm not understanding it, but in the OSM inspector [1] I just see one
case of old style multipolygon, in Manitoba. Last week, when you posted your
original message, I just saw one case in New Brunswick. IIRC, it was a park,
not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are on the
outer ways and not on the relation), but multipolygons where the tags
are on the relation AND on the ways.

Ah, ok, now I understand. Since there was a lot of discussion about old
style multipolygon tagging, and since this type of problem hasn't been added
to OSM inspector,  this wasn't immediately obvious.


In the OSM inspector other errors can be seen, but the most prevalent one is
"Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
which seems urgent to me.

Here is an example of a forest multipolygon, imported by me
(canvec_fsteggink). It is still version 1, but it has tags on the relation,
not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such
cases in the OSM inspector.

So, I'd like to ask you to give a couple of examples where data imported
from Canvec is clearly wrong with regard to old style multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954 226a3acab882d28d8500ddef8203d/ same-tags-ca.pbf

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/r elation/541821

How difficult would it be to add this to OSM inspector? Not everybody has
Postgres running, and is able to use osm2pgsql. Yes, there is documentation,
but it requires some technical skills. Also, it would be very convenient to
have this updated daily.

It is not that difficult to add to the OSM Inspector and if I have the
time I'll work on that together with the Geofabrik people.




When we have clear examples, then it might be easier to come up with a plan
how to fix it. But so far, I see absolutely no reason why Canada stands out
in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
but as others already have pointed out, mapping 

[OSM-talk-be] Potlatch crasht keer op keer

[Karel Adams]

Already for a couple of weeks, Potlatch crashes when I try to add a 
"blank node" to serve as a beginning of a way.


For those who didn't yet know: I am almost exclusively into mapping 
aerdromes, and prefer Potlatch. I can, and still do, add aerodromes by 
dragging the relevant icon into map, no issue there. But I can no more 
add runways: when I click the first end point, there is an immediate 
crash. Not really of Potlatch but rather of the underlying "Adobe Flash 
plugin". I've already sent tons of error reports, and updated versions 
of the Flash plugin have appeared and were duly installed, still no 
improvement.


What can be done?

Environment: Ubuntu 16.04+ Firefox, both religiously patched up to date.



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

Re: [Talk-ca] Multipolygon problems

[James]

Error free Québec, just in time for Canada day! Good job Pierre :-)

On Jul 1, 2017 4:34 AM, "Frank Steggink"  wrote:

> Hi Jochen,
>
> Maybe a MapRoulette challenge might even not be necessary. Yesterday I
> started to clean up a bit in Québec, but since it was already past midnight
> for me, I wanted to continue this morning. To my surprise Pierre has done a
> lot of work and now the entire province of Québec looks to be free from
> these errors. I just could find three errors, and fixed them. Bon travail,
> Pierre!
>
> The OSM inspector will still be a good idea, in order to spot future
> errors.
>
> To all, this is the procedure I used yesterday, and probably something
> similar also by Pierre.
> * Not sure if it is a requirement, but it's better to use 64 bit Java.
> * You'll need JOSM with the remote control plugin. You'll also need to
> start JOSM.
> * Use Pierre's Overpass query (http://overpass-turbo.eu/s/q5K), and
> zoom/pan to the area of interest.
> * Press Run and let Overpass do its work. Don't be afraid when Overpass
> mentions that the result is huge if you have a modern computer. Last night
> I wasn't experiencing any problems with 30MB data.
> * Press Export, and choose JOSM. Press "Repair query" when Overpass asks
> you to decide.
> * JOSM starts downloading the data. Note that you're only getting the
> outer rings.
> * Go to these rings one by one, and load data (at least you'll need the
> relationship itself).
> * Remove the natural=wood tag from the outer ring.
> * Eventually JOSM starts looking cluttered, because of all the extra data.
> You can use the search query "type:way natural=wood role:outer" to see if
> there are still rings needing work.
> * Upload your changes. Be prepared to handle conflicts if someone else is
> working near you on this issue as well.
> * After a while, check Overpass Turbo again.
>
> I'm not sure what the update frequency is, but Pierre's changes from 4
> hours ago were already processed.
>
> Good luck!
>
> Frank
>
>
> On 01-07-2017 09:52, Jochen Topf wrote:
>
>> On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote:
>>
>>> On 30-06-2017 21:21, Jochen Topf wrote:
>>>
 On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:

> Maybe I'm not understanding it, but in the OSM inspector [1] I just
> see one
> case of old style multipolygon, in Manitoba. Last week, when you
> posted your
> original message, I just saw one case in New Brunswick. IIRC, it was a
> park,
> not even from the Canvec import.
>
 The types of problems I am talking about don't show up in the OSM
 inspector. This is not old-style multipolygons (where tags are on the
 outer ways and not on the relation), but multipolygons where the tags
 are on the relation AND on the ways.

>>> Ah, ok, now I understand. Since there was a lot of discussion about old
>>> style multipolygon tagging, and since this type of problem hasn't been
>>> added
>>> to OSM inspector,  this wasn't immediately obvious.
>>>
 In the OSM inspector other errors can be seen, but the most prevalent
> one is
> "Touching rings". Maybe indeed a case of suboptimal mapping, but
> nothing
> which seems urgent to me.
>
> Here is an example of a forest multipolygon, imported by me
> (canvec_fsteggink). It is still version 1, but it has tags on the
> relation,
> not on the rings (except for the quarries): [2]
> This is from Canvec v7.0. IIRC, we started at v6.0, and the last
> version I
> know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any
> such
> cases in the OSM inspector.
>
> So, I'd like to ask you to give a couple of examples where data
> imported
> from Canvec is clearly wrong with regard to old style multipolygon
> tagging.
>
 Here are all cases in Canada (not only those from the imports):
 https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/
 same-tags-ca.pbf

 Here is one example where you can clearly see the problem:
 http://www.openstreetmap.org/relation/541821

>>> How difficult would it be to add this to OSM inspector? Not everybody has
>>> Postgres running, and is able to use osm2pgsql. Yes, there is
>>> documentation,
>>> but it requires some technical skills. Also, it would be very convenient
>>> to
>>> have this updated daily.
>>>
>> It is not that difficult to add to the OSM Inspector and if I have the
>> time I'll work on that together with the Geofabrik people.
>>
>> When we have clear examples, then it might be easier to come up with a
> plan
> how to fix it. But so far, I see absolutely no reason why Canada
> stands out
> in a negative way. Yes, we all acknowledge that Canvec data is
> suboptimal,
> but as others already have pointed out, mapping everything by hand in
> especially remote areas is nearly impossible.
>
 Canada stands out in a 

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

[Noémie Lehuby]

Hello,

Jo, tu parles des règles pour le validateur JOSM que j'ai créées ?
https://github.com/nlehuby/transport_mapcss
C'est encore du "work in progress", mais je suis effectivement basée 
surles réseaux que je connais, je ne sais pas si ça se reproduit bien 
ailleurs.


Chez nous, les arrêts de bus sont des éléments de mobilier urbain, ils 
sont donc plutôt sous la responsabilité des villes que des opérateurs de 
transports. Il n'est d'ailleurs pas rare que, lorsqu'une ligne traverse 
plusieurs villes, les arrêts d'une même ligne changent complètement de 
design d'une ville à l'autre.
C'est pour cela qu'il me semble plus pertinent de faire porter les tags 
operator et network par les lignes de transports plutôt que par les arrêts.

C'est peut-être une spécificité française, je ne sais pas ?


Idéalement, dans le futur, une fois que ces règles seront stabilisées, 
elles seraient réintégrées dans JOSM (pourquoi pas dans le plugin PT 
assistant ;)) et dans Osmose, pour qu'elles soient traduites et 
directement accessibles dans les outils utilisés par les contributeurs.


D'ailleurs si vous les utilisez, n'hésitez pas à me faire des retours 
sur ces règles sur la liste transport, par mail ou sur github.


Noémie

Le 01/07/2017 à 13:18, Jo a écrit :

Salut Noémie,

Ils ne sont qu'en français. Comment s'y prendre pour traduire, au 
moins en anglais. Ou c'est vraiment dédié qu'à la France?


Pour les arrêts, nous mettons operator et network en Belgique, séparé 
par ; si l'arrêt est désservi par plusieurs opérateurs. Ça va donc 
résulter en 70k avertissements par nos cotés.


Jo

2017-07-01 10:14 GMT+02:00 Noémie Lehuby 
>:


Bonjour,

Nouveau mois, nouveau projet du mois !

Vous ne les remarquez plus tellement ils font partie du paysage
urbain (ou pas), pourtant il en manque encore pas mal sur la carte !
Ce mois-ci je vous propose de cartographier ensemble les arrêts de
bus !

Comme d'habitude, rendez-vous sur le wiki pour plus d'infos :


https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/arr%C3%AAts_de_bus





@nlehuby




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

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

[Frédéric Rodrigo]

Salut,

Pour fêter ça Osmose propose d'intégrer maintenant les arrêts sur Nancy.

http://osmose.openstreetmap.fr/fr/map/#item=8040%2C8041=15=48.69607=6.17944=1%2C2%2C3

N'hésitez pas à faire un retour, notamment si la référence ne semble pas 
bonne.


(Il y a "None" dans les popups mais ça va être corrigé)

Comme c'est basé sur le GTFS on peu facilement en ajouter pour d'autres 
ville, si elle n'y est pas déjà.

http://osmose.openstreetmap.fr/fr/errors/?item=8040
Il faut juste déterminer à quoi correspond dans OSM l'arrêt décrit dans 
le GTFS.



Frédéric.



Le 01/07/2017 à 10:14, Noémie Lehuby a écrit :

Bonjour,

Nouveau mois, nouveau projet du mois !

Vous ne les remarquez plus tellement ils font partie du paysage urbain 
(ou pas), pourtant il en manque encore pas mal sur la carte !

Ce mois-ci je vous propose de cartographier ensemble les arrêts de bus !

Comme d'habitude, rendez-vous sur le wiki pour plus d'infos :

https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/arr%C3%AAts_de_bus 




@nlehuby




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

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

[Dlareg]

Bonjour,

Le 01/07/2017 à 13:18, Jo a écrit :
> Ils ne sont qu'en français. Comment s'y prendre pour traduire, au moins
> en anglais. Ou c'est vraiment dédié qu'à la France?

Qu'est ce qui n'est qu'en français ?

-- 
Dlareg

Les publicités pour les entreprises transnationales ne sont pas des cas
isolés
http://citedelagastro-dijon.com/

La Cité de la gastronomie est un parc à thème
http://www.dlareg.org/post/2014/11/19/Dans-la-cité-de-la-gastronomie-la-publicité-s-affiche




signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] SEO Damage to OSM

[Simon Poole]

Am 01.07.2017 um 12:48 schrieb Walter Nordmann:

> hi simon,
>
>
> Am 01.07.2017 um 08:33 schrieb Simon Poole:
>>
>> I've already touched on this with the sys admins and saved refs to
>> the ones that I fixed. However it is unlikely that we will do any
>> thing with the information as the accounts are extremely unlikely to
>> be reused, and on the other hand, given that *we have a known US
>> based SEO company that has created (literally) 1000s of such
>> accounts* (but with slightly less spammy edits), and "we" haven't
>> taken any action, why should we in this case?
> what's about a captcha to disable automatic registration? and a
> confirmation mail, which is asking a variable question too?
>
n the case I was referring too, see
http://www.openstreetmap.org/user/SimonPoole/diary/40246 , we are fairly
sure that it is a sweatshop that is/was adding them. Outside of causing
issues for legitimate users, adding a captcha  is likely not to achieve
anything

Simon


> Regards
> walter aka wambacher
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us



signature.asc
Description: OpenPGP digital signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

[Jo]

Salut Noémie,

Ils ne sont qu'en français. Comment s'y prendre pour traduire, au moins en
anglais. Ou c'est vraiment dédié qu'à la France?

Pour les arrêts, nous mettons operator et network en Belgique, séparé par ;
si l'arrêt est désservi par plusieurs opérateurs. Ça va donc résulter en
70k avertissements par nos cotés.

Jo

2017-07-01 10:14 GMT+02:00 Noémie Lehuby :

> Bonjour,
>
> Nouveau mois, nouveau projet du mois !
>
> Vous ne les remarquez plus tellement ils font partie du paysage urbain (ou
> pas), pourtant il en manque encore pas mal sur la carte !
> Ce mois-ci je vous propose de cartographier ensemble les arrêts de bus !
>
> Comme d'habitude, rendez-vous sur le wiki pour plus d'infos :
>
> https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/
> arr%C3%AAts_de_bus
>
>
> @nlehuby
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] SEO Damage to OSM

[Walter Nordmann]

hi simon,


Am 01.07.2017 um 08:33 schrieb Simon Poole:


I've already touched on this with the sys admins and saved refs to the 
ones that I fixed. However it is unlikely that we will do any thing 
with the information as the accounts are extremely unlikely to be 
reused, and on the other hand, given that *we have a known US based 
SEO company that has created (literally) 1000s of such accounts* (but 
with slightly less spammy edits), and "we" haven't taken any action, 
why should we in this case?
what's about a captcha to disable automatic registration? and a 
confirmation mail, which is asking a variable question too?


Regards
walter aka wambacher
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] repérage géolocalisé sur le terrain

[marc marc]

 > Osmand affiche aussi un cercle dont le rayon représente
 > cette incertitude.
J'ai fais hier un peu plus attention au cercle dans Go Map!
On voit clairement 2 effets différents :
L'imprécision bien connue au démarrage où le cercle est grand.
Mais quand la localisation fait des bonds, le cercle reste étroit,
la position réelle est alors très fortement hors du cercle.

Le 30. 06. 17 à 23:18, osm.sanspourr...@spamgourmet.com a écrit :
> Pour la précision, ce qui t'intéresse c'est la HDOP (Horizontal Dilution 
> Of Precision), info fournie par le GPS.
Merci pour l'info.
> OSMTracker qui permet d'enregistrer le trajet avec la précision horizontale 
> (qui est d'ailleurs affichée).
Je vais le tester. Mais ensuite comment utilise-t-on cette info ?
Il existe un outil pour faire ressortir les photos correspondant à un 
moment oü le HDOP est mauvais ? OSMTracker lui même permet-il de générer 
une alerte visuelle ou sonore ?
Car au final, à pied, quand le signal est mauvais, la meilleur solution 
est souvent d'attendre quelques secondes avant de prendre la photo.
> Je comptais signaler à Christian et Stéphane que j'avais vu que le 
> BeagleBoard Bone Black  pouvait supporter une 
> carte compatible RTKLib. De l'électronique libre (plus durcie que le 
> Rapsberry) ça va bien avec du logiciel libre et une carto collaborative.
Je partage tout à fait ton avis sur la cohérence matériel-logiciel-donnée.
Mais fait-tu si souvent de l'enregistrement de trace au point de 
justifier un appareil dédié ?
Pour ma part, cela se limite à quelques chemins piétonniers et quelques 
emprises de nouveau bâtiments non présent sur les images satellites.
La donne serrait différente s'il devenait facile (=automatiser par lot) 
d'améliorer la localisation des photos concernées.

 > (plus durcie que le Rapsberry)
que veux-tu dire ? une meilleur résistance mécanique/électrique ?

> (*) Chez Pomme ils doivent appeler un 4s un trognon.
excellent !

En passant, existe-t-il des appareils (financièrement accessible) avec 
DGPS, EGNOS ou équivalent ? quelle précision en obtient-on ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Import non andato a buon fine

[MaxDragonheart]

Ok, grazie per le indicazioni. Appena a casa leggo nel dettaglio il link
che mi hai inviato.

Ritieni corretto che elimino i dati caricati tra ieri e l'altro ieri?
Se, in virtù della procedura che mi hai indicato, si, posso eliminarli al
massimo entro domani. :)

Il 1 lug 2017 11:02 AM, "dieterdreist [via GIS]" <
ml+s19327n5898616...@n8.nabble.com> ha scritto:

>
> 2017-06-30 21:57 GMT+02:00 MaxDragonheart <[hidden email]
> >:
>
>> Ho cercato di rispettare le wiki che avevo già letto caricando dati che
>> sono
>> sicuramente corretti dal punto di vista topologico e cartografico in
>> generale.
>>
>
>
> va benissimo se i dati sono corretti :)
>
> Comunque, per fare un import bisogno rispettare la procedura import, ciò
> vuol dire: coinvolgere la comunità (prima di fare l'upload), creare una
> pagina apposita per l'import, rendere i dati "finali" che si intende di
> caricare, pubblici e visionabili dagli altri utenti, annunciare l'import in
> lista nazionale o regionale e "import" (internazionale). Qui ti puoi fare
> un'idea: https://lists.openstreetmap.org/pipermail/imports/2017-
> June/thread.html
>
> Dopo qualche settimana, se tutti i problemi sono discussi / risolti e
> l'import è stato documentato nella wiki, puoi provedere all'import (upload
> su osm) con un account dedicato. Dopodichè sarebbe utile mettere i numeri
> dei changeset del upload sulla pagina del wiki come documentazione.
>
> Questo era la versione breve (e forse incompleta), in più dettaglio la
> procedura la puoi vedere qui: https://wiki.openstreetmap.org
> /wiki/Import/Guidelines
>
> Ciao,
> Martin
>
> ___
> Talk-it mailing list
> [hidden email] 
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://gis.19327.n8.nabble.com/Import-non-andato-a-buon-
> fine-tp5898578p5898616.html
> To unsubscribe from Import non andato a buon fine, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://gis.19327.n8.nabble.com/Import-non-andato-a-buon-fine-tp5898578p5898617.html
Sent from the Italy General mailing list archive at Nabble.com.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-be] open summer of code: cycling event

[Philippe Casteleyn]

Ik zal mijn camera' s en RAM mounts voor velo meedoen.  Kan iemand Gopro 
uitrusting meedoen ?
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-it] Import non andato a buon fine

[Martin Koppenhoefer]

2017-06-30 21:57 GMT+02:00 MaxDragonheart :

> Ho cercato di rispettare le wiki che avevo già letto caricando dati che
> sono
> sicuramente corretti dal punto di vista topologico e cartografico in
> generale.
>


va benissimo se i dati sono corretti :)

Comunque, per fare un import bisogno rispettare la procedura import, ciò
vuol dire: coinvolgere la comunità (prima di fare l'upload), creare una
pagina apposita per l'import, rendere i dati "finali" che si intende di
caricare, pubblici e visionabili dagli altri utenti, annunciare l'import in
lista nazionale o regionale e "import" (internazionale). Qui ti puoi fare
un'idea:
https://lists.openstreetmap.org/pipermail/imports/2017-June/thread.html

Dopo qualche settimana, se tutti i problemi sono discussi / risolti e
l'import è stato documentato nella wiki, puoi provedere all'import (upload
su osm) con un account dedicato. Dopodichè sarebbe utile mettere i numeri
dei changeset del upload sulla pagina del wiki come documentazione.

Questo era la versione breve (e forse incompleta), in più dettaglio la
procedura la puoi vedere qui: https://wiki.openstreetmap.
org/wiki/Import/Guidelines

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSRM-talk] Example of restricted access flags for way_function and turn_function

[Daniel Hofmann]

You are correct, the way function can set a "restricted" flag per way (and
direction), which you can then use in the turn function to put a high
penalty on turns from/to "restricted" ways.

The general idea is outlined here:

https://www.openstreetmap.org/user/happygo/diary/40564

Have a look at ExtractionWay, ExtractionTurn and the EdgeBasedGraphFactory.

Cheers,
Daniel J H

On Sat, Jul 1, 2017 at 12:08 AM, Mateusz Loskot  wrote:

> Hi,
>
> I'm trying to learn about use of the way_function result flags,
> forward_restricted and backward_restricted, and their correspondence
> with turn_function machinery, especially input source_restricted and
> target_restricted flags.
>
> Is there any data and profile example which shoes these in action?
>
> I guess, way_function is called first and any of the restriction flags set
> here for the link are passed to turn_function. Correct?
>
> Disclaimer: I haven't looked into OSRM implementation details yet,
> which, once grasped, I guess, might be enlightening.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[Talk-se] stuglandet

[Martin Norbäck Olivers]

En hypotetisk fråga. Om man skulle vilja koppla stugorna i t.ex. denna bok
till openstreetmap, skulle det vara ok?

http://www.adlibris.com/se/bok/stuglandet-en-guide-till-fria-overnattningar-9789188435200
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

Hi Jochen,

Maybe a MapRoulette challenge might even not be necessary. Yesterday I 
started to clean up a bit in Québec, but since it was already past 
midnight for me, I wanted to continue this morning. To my surprise 
Pierre has done a lot of work and now the entire province of Québec 
looks to be free from these errors. I just could find three errors, and 
fixed them. Bon travail, Pierre!


The OSM inspector will still be a good idea, in order to spot future errors.

To all, this is the procedure I used yesterday, and probably something 
similar also by Pierre.

* Not sure if it is a requirement, but it's better to use 64 bit Java.
* You'll need JOSM with the remote control plugin. You'll also need to 
start JOSM.
* Use Pierre's Overpass query (http://overpass-turbo.eu/s/q5K), and 
zoom/pan to the area of interest.
* Press Run and let Overpass do its work. Don't be afraid when Overpass 
mentions that the result is huge if you have a modern computer. Last 
night I wasn't experiencing any problems with 30MB data.
* Press Export, and choose JOSM. Press "Repair query" when Overpass asks 
you to decide.
* JOSM starts downloading the data. Note that you're only getting the 
outer rings.
* Go to these rings one by one, and load data (at least you'll need the 
relationship itself).

* Remove the natural=wood tag from the outer ring.
* Eventually JOSM starts looking cluttered, because of all the extra 
data. You can use the search query "type:way natural=wood role:outer" to 
see if there are still rings needing work.
* Upload your changes. Be prepared to handle conflicts if someone else 
is working near you on this issue as well.

* After a while, check Overpass Turbo again.

I'm not sure what the update frequency is, but Pierre's changes from 4 
hours ago were already processed.


Good luck!

Frank


On 01-07-2017 09:52, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote:

On 30-06-2017 21:21, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:

Maybe I'm not understanding it, but in the OSM inspector [1] I just see one
case of old style multipolygon, in Manitoba. Last week, when you posted your
original message, I just saw one case in New Brunswick. IIRC, it was a park,
not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are on the
outer ways and not on the relation), but multipolygons where the tags
are on the relation AND on the ways.

Ah, ok, now I understand. Since there was a lot of discussion about old
style multipolygon tagging, and since this type of problem hasn't been added
to OSM inspector,  this wasn't immediately obvious.

In the OSM inspector other errors can be seen, but the most prevalent one is
"Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
which seems urgent to me.

Here is an example of a forest multipolygon, imported by me
(canvec_fsteggink). It is still version 1, but it has tags on the relation,
not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such
cases in the OSM inspector.

So, I'd like to ask you to give a couple of examples where data imported
from Canvec is clearly wrong with regard to old style multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/relation/541821

How difficult would it be to add this to OSM inspector? Not everybody has
Postgres running, and is able to use osm2pgsql. Yes, there is documentation,
but it requires some technical skills. Also, it would be very convenient to
have this updated daily.

It is not that difficult to add to the OSM Inspector and if I have the
time I'll work on that together with the Geofabrik people.


When we have clear examples, then it might be easier to come up with a plan
how to fix it. But so far, I see absolutely no reason why Canada stands out
in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
but as others already have pointed out, mapping everything by hand in
especially remote areas is nearly impossible.

Canada stands out in a negative way, because
a) there are so many problems. Nearly a third of the cases worldwide are in
 Canada and
b) most of these problems are probably caused by one little program, the
 program used to convert/import the CanVec data.

As you might have noticed, later imports, like the example I provided, don't
have that issue anymore. I'm mentioning this to express that not _all_
Canvec data is at fault! Only the first couple of versions. However, for
some reason this was never noticed up until a point that collaborative
action was done to have 

[OSM-talk-fr] Projet du mois - arrêts de bus

[Noémie Lehuby]

Bonjour,

Nouveau mois, nouveau projet du mois !

Vous ne les remarquez plus tellement ils font partie du paysage urbain 
(ou pas), pourtant il en manque encore pas mal sur la carte !

Ce mois-ci je vous propose de cartographier ensemble les arrêts de bus !

Comme d'habitude, rendez-vous sur le wiki pour plus d'infos :

https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/arr%C3%AAts_de_bus 




@nlehuby


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

Re: [Talk-ca] Multipolygon problems

[Jochen Topf]

On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote:
> On 30-06-2017 21:21, Jochen Topf wrote:
> > On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:
> > > Maybe I'm not understanding it, but in the OSM inspector [1] I just see 
> > > one
> > > case of old style multipolygon, in Manitoba. Last week, when you posted 
> > > your
> > > original message, I just saw one case in New Brunswick. IIRC, it was a 
> > > park,
> > > not even from the Canvec import.
> > The types of problems I am talking about don't show up in the OSM
> > inspector. This is not old-style multipolygons (where tags are on the
> > outer ways and not on the relation), but multipolygons where the tags
> > are on the relation AND on the ways.
> Ah, ok, now I understand. Since there was a lot of discussion about old
> style multipolygon tagging, and since this type of problem hasn't been added
> to OSM inspector,  this wasn't immediately obvious.
> > > In the OSM inspector other errors can be seen, but the most prevalent one 
> > > is
> > > "Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
> > > which seems urgent to me.
> > > 
> > > Here is an example of a forest multipolygon, imported by me
> > > (canvec_fsteggink). It is still version 1, but it has tags on the 
> > > relation,
> > > not on the rings (except for the quarries): [2]
> > > This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
> > > know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any 
> > > such
> > > cases in the OSM inspector.
> > > 
> > > So, I'd like to ask you to give a couple of examples where data imported
> > > from Canvec is clearly wrong with regard to old style multipolygon 
> > > tagging.
> > Here are all cases in Canada (not only those from the imports):
> > https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf
> > 
> > Here is one example where you can clearly see the problem:
> > http://www.openstreetmap.org/relation/541821
> How difficult would it be to add this to OSM inspector? Not everybody has
> Postgres running, and is able to use osm2pgsql. Yes, there is documentation,
> but it requires some technical skills. Also, it would be very convenient to
> have this updated daily.

It is not that difficult to add to the OSM Inspector and if I have the
time I'll work on that together with the Geofabrik people.

> > > When we have clear examples, then it might be easier to come up with a 
> > > plan
> > > how to fix it. But so far, I see absolutely no reason why Canada stands 
> > > out
> > > in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
> > > but as others already have pointed out, mapping everything by hand in
> > > especially remote areas is nearly impossible.
> > Canada stands out in a negative way, because
> > a) there are so many problems. Nearly a third of the cases worldwide are in
> > Canada and
> > b) most of these problems are probably caused by one little program, the
> > program used to convert/import the CanVec data.
> As you might have noticed, later imports, like the example I provided, don't
> have that issue anymore. I'm mentioning this to express that not _all_
> Canvec data is at fault! Only the first couple of versions. However, for
> some reason this was never noticed up until a point that collaborative
> action was done to have it fixed. Probably because the rendering pipeline of
> the slippy map was accepting this kind of tagging up until recently.

Okay, that is a big relief already. At least we are not making this
problem worse by new imports that might happen in the future.

> > Mapping Canada "by hand" might be difficult because it is such a huge
> > country and there aren't that many mappers. But the same arguments goes
> > for why you have to be extra careful importing data. If you break
> > something, there are not enough people to fix it manually. And, yes,
> > errors do happen. And if we find them, we fix them and move on. But
> > errors from imports can be so huge there aren't enough people there to
> > fix them manually.
> The world is so huge that there aren't enough people to create and maintain
> a global world map. However, OSM exists. Fixing errors can also be
> crowdsourced. Martijn van Exel is really doing a great job with MapRoulette,
> for instance. Although fixing errors (cleaning up the mess left behind by
> others) is not nearly as rewarding as mapping, it might be easier to do,
> especially since there is no need for a lot of creativity when fixing the
> same kind of errors.

You might have seen that I spent a lot of time in the last months to
create more than 60 Maproulette challenges for all sorts of different
multipolygon problems in different communities. And the community worked
tirelessly on all these problems. (http://area.jochentopf.com/fixed.html)

If the Canadian community steps up and is willing to do this work
manually, I'd he happy to provide such Maproulette 

Re: [Talk-us] SEO Damage to OSM

[Simon Poole]

Am 01.07.2017 um 03:54 schrieb Clifford Snow:
> Simon,
> Thanks for looking at them. Fortunately there wasn't too many to fix
> mannually. Some of vandalism goes back 2 or 3 years if I recall
> correctly. I did check Canada thinking that they might have hit them
> as well, but other than some strange addresses on ways, it was clean.
>
> Ian Dees did fixed the remaining of the problems. 
>
> I plan to look at the original changesets to see if there is any clue
> which company was behind it. Do you know if I gave the systems admin
> people a list of user if they could check the email used to create the
> account belongs to one company?

I've already touched on this with the sys admins and saved refs to the
ones that I fixed. However it is unlikely that we will do any thing with
the information as the accounts are extremely unlikely to be reused, and
on the other hand, given that we have a known US based SEO company that
has created (literally) 1000s of such accounts (but with slightly less
spammy edits), and "we" haven't taken any action, why should we in this
case?

Simon

>
> On Fri, Jun 30, 2017 at 1:26 PM, Simon Poole  > wrote:
>
> I''m in the process of fixing a couple of these. and I couldn't
> help noticing that some of them can't simply be reverted because
> the TeleNav data team has added lane tagging on them 
>
> Simon
>
>
> Am 30.06.2017 um 18:21 schrieb Clifford Snow:
>> Edits, from what appears to be a search engine optimization
>> company (SEO), have damaged a number of ways in the US. Martijn
>> Van Exel pointed out the problem on Slack the other day. What
>> they did was to add their client to a street, often changing the
>> name of the street to the company.  Fortunately they made it easy
>> to find using overpass [1] by adding in the clients address,
>> phone number, source and website. The query looks for addresses
>> and websites on ways. 
>>
>> West of the Mississippi has been fixed. There are some false
>> positives when running the query, they are all park polygons with
>> both leisure=park and highway=pedestrian. The website url is of
>> the park.
>>
>> If someone would like to help clean up the rest of damage they
>> did, just run the overpass query for an area, state, county, etc.
>> to get a list of ways that match the query. From there just
>> select the way which will open OSM in another tab where you can
>> use your favorite editor to fix. Use the history feature or TIGER
>> data to get the correct road name. The addr:street they added may
>> not be anywhere near your way. 
>>
>> [1] http://overpass-turbo.eu/s/q5A
>>
>> Thanks,
>> Clifford
>>
>> -- 
>> @osm_seattle
>> osm_seattle.snowandsnow.us 
>> OpenStreetMap: Maps with a human touch
>>
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-us
>> 
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us
> 
>
>
>
>
> -- 
> @osm_seattle
> osm_seattle.snowandsnow.us 
> OpenStreetMap: Maps with a human touch
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us



signature.asc
Description: OpenPGP digital signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us