Re: [OSM-talk-fr] Sur 01net L’incroyable histoire de Waze, la carte routière la plus précise au monde... conçue par des bénévoles

[Vladimir Vyskocil]

C’est un peu faux culs de ne pas parler de ce qui a vraiment fait le succès de 
Waze, je veux parler du signalement en temps réel des radars et des contrôles 
de police…
Avec l’arrivée de Google et les nouvelles lois cela a été un peu camouflé mais 
les habitudes ont été prises par la communauté des utilisateurs et il n’est pas 
rare aujourd’hui de voir un radar précisément signalé avec une alerte de danger 
plus “générique"…

Vlad.

> On 6 Oct 2019, at 10:45, PierreV  wrote:
> 
> https://www.01net.com/actualites/l-incroyable-histoire-de-waze-la-carte-routiere-la-plus-precise-au-monde-concue-par-des-benevoles-1777628.html
> 
> On contacte 01net pour leur proposer un article sur OSM qui est encore plus
> "génial" que Waze car réutilisable par n'importe qui?
> 
> Par contre le fait que waze n'utile pas de "fonds cartographique"
> contrairement a OSM, c'est un peu faux :
> car d'après wikipédia Waze a acheté quelques données dans certains pays
> 
> apparemment c'est le premier d'une série d'articles:
> https://twitter.com/LelloucheNico/status/1180427218067087362
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk] Abuse of natural=cliff tag

[Vladimir Vyskocil]

> On 11 Sep 2019, at 20:20, Mark Wagner  wrote:
> 
> 
> On Wed, 11 Sep 2019 15:33:05 +0200
> Vladimir Vyskocil  wrote:
> 
>> A even crazier area regarding the abuse of the cliff tag ! 
>> 
>> https://www.openstreetmap.org/#map=15/50.9610/14.0724
>> <https://www.openstreetmap.org/#map=15/50.9610/14.0724>
> 
> Doesn't look crazy to me.  From what I saw on the map, I expected there
> to be rock formations of the sort you'd find in south Utah.  Switching
> to aerial imagery, I saw pretty much that, just with more trees.

https://www.openstreetmap.org/edit#map=20/50.96391/14.06867 
<https://www.openstreetmap.org/edit#map=20/50.96391/14.06867> really ?

> 
> (Is now tempted to map Bryce Canyon in excruciating detail.)
> 
> -- 
> Mark
> 
> ___
> 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] Abuse of natural=cliff tag

[Vladimir Vyskocil]

Hi ! 

> On 11 Sep 2019, at 15:33, Vladimir Vyskocil  
> wrote:
> 
> A even crazier area regarding the abuse of the cliff tag ! 
> 
> https://www.openstreetmap.org/#map=15/50.9610/14.0724 
> <https://www.openstreetmap.org/#map=15/50.9610/14.0724>
What I see there is far from reasonable and far for common sens, it is just 
wrong and mad...
All this bad information about cliffs in that area ie what common sens think is 
a real cliff and what is explained in the openstreetmap wiki page about this 
tag impact the usability of the data and I even don’t talk about the rendering, 
we are not tagging for the renderer but we easily could see that this tag was 
not designed for this mess !

Now have a look please at the Grand Canyon in USA, for example :

https://www.openstreetmap.org/#map=14/36.0765/-112.1345 
<https://www.openstreetmap.org/#map=14/36.0765/-112.1345>

This is useful information ! How do you think It had looked if every little 
stones or slopes were mapped as a cliff like it is in the area we are talking 
about ?

Vladimir.

> 
> Vladimir.
> 
>> Le 11 sept. 2019 à 15:27, Vladimir Vyskocil > <mailto:vladimir.vysko...@gmail.com>> a écrit :
>> 
>> Hello Sarah,
>> 
>> I read carefully your response and looked at the picture. I didn't travelled 
>> exactly at this place but will go there in October ! However I've already 
>> been in Český ráj 
>> <http://www.cesky-raj.info/en/contacts/bohemian-paradise-association/> that 
>> is not too far from there and where the terrain is similar in many aspects.
>> I still think that the usage of the tag is abused in this area…
>> You may read the description of this tag here :
>> 
>> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff 
>> <https://wiki.openstreetmap.org/wiki/Tag:natural=cliff>
>> 
>> «  A cliff <http://en.wikipedia.org/wiki/en:cliff> is a vertical or almost 
>> vertical natural drop in terrain topography as it occurs for example in form 
>> of coastal cliffs or escarpments. The face of the cliff usually consists of 
>> bare solid rock but can occasionally also consist of clay, compacted sand, 
>> ice or other solid materials.» 
>> 
>> 
>> « 
>> When not to use
>> natural <https://wiki.openstreetmap.org/wiki/Key:natural>=cliff <> should 
>> not be used for ridges, i.e. crests where there is a significant drop in 
>> terrain to both sides and neither of them is close to vertical. Use natural 
>> <https://wiki.openstreetmap.org/wiki/Key:natural>=ridge 
>> <https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge> or natural 
>> <https://wiki.openstreetmap.org/wiki/Key:natural>=arete 
>> <https://wiki.openstreetmap.org/wiki/Tag:natural%3Darete> instead. Also do 
>> not usenatural <https://wiki.openstreetmap.org/wiki/Key:natural>=cliff <> 
>> just for mapping an inclined bare rock surface, use natural 
>> <https://wiki.openstreetmap.org/wiki/Key:natural>=bare_rock 
>> <https://wiki.openstreetmap.org/wiki/Tag:natural%3Dbare_rock> instead.
>> 
>> " 
>> 
>> This is not what I see when I look at this mapped area, I agree that some 
>> mapped cliffs here are really what should be considered a cliff but they are 
>> lost in lots of wrongly mapped and not relevant ones. 
>> 
>> You might look at this as a example in many many more :
>> 
>> https://www.openstreetmap.org/#map=19/50.89893/14.28319 
>> <https://www.openstreetmap.org/#map=19/50.89893/14.28319>
>> 
>> We are seeing it at level 19 and the density of cliffs is still crazy ! 
>> 
>> Or here : https://www.openstreetmap.org/#map=15/50.8791/14.3647 
>> <https://www.openstreetmap.org/#map=15/50.8791/14.3647>
>> 
>> Could you tell me that all theses mapped cliffs really exists ? Or aren’t 
>> they just « a significant drop in terrain and neither of them are close to 
>> vertical » mapped as cliffs only looking at terrain model and that are 
>> completely disconnected from the reality of the terrain ?
>> 
>> Regards,
>> Vladimir
>> 
>> 
>> 
>>> Le 11 sept. 2019 à 00:17, Sarah Hoffmann >> <mailto:lon...@denofr.de>> a écrit :
>>> 
>>> Hi,
>>> 
>>> On Fri, Sep 06, 2019 at 02:42:06PM +0200, Vladimir Vyskocil wrote:
>>>> Around this area : https://www.openstreetmap.org/#map=16/50.9034/14.2763 
>>>> <https://www.openstreetmap.org/#map=16/50.9034/14.2763> 
>>>> <https://www.openstreetmap.org/#map=16/50.9034/14.2763 
>>>> <https://www.openstreetmap.org/#map=16/50.9034/14.2763>> 

Re: [OSM-talk] Abuse of natural=cliff tag

[Vladimir Vyskocil]

A even crazier area regarding the abuse of the cliff tag ! 

https://www.openstreetmap.org/#map=15/50.9610/14.0724 
<https://www.openstreetmap.org/#map=15/50.9610/14.0724>

Vladimir.

> Le 11 sept. 2019 à 15:27, Vladimir Vyskocil  a 
> écrit :
> 
> Hello Sarah,
> 
> I read carefully your response and looked at the picture. I didn't travelled 
> exactly at this place but will go there in October ! However I've already 
> been in Český ráj 
> <http://www.cesky-raj.info/en/contacts/bohemian-paradise-association/> that 
> is not too far from there and where the terrain is similar in many aspects.
> I still think that the usage of the tag is abused in this area…
> You may read the description of this tag here :
> 
> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff 
> <https://wiki.openstreetmap.org/wiki/Tag:natural=cliff>
> 
> «  A cliff <http://en.wikipedia.org/wiki/en:cliff> is a vertical or almost 
> vertical natural drop in terrain topography as it occurs for example in form 
> of coastal cliffs or escarpments. The face of the cliff usually consists of 
> bare solid rock but can occasionally also consist of clay, compacted sand, 
> ice or other solid materials.» 
> 
> 
> « 
> When not to use
> natural <https://wiki.openstreetmap.org/wiki/Key:natural>=cliff <> should not 
> be used for ridges, i.e. crests where there is a significant drop in terrain 
> to both sides and neither of them is close to vertical. Use natural 
> <https://wiki.openstreetmap.org/wiki/Key:natural>=ridge 
> <https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge> or natural 
> <https://wiki.openstreetmap.org/wiki/Key:natural>=arete 
> <https://wiki.openstreetmap.org/wiki/Tag:natural%3Darete> instead. Also do 
> not use natural <https://wiki.openstreetmap.org/wiki/Key:natural>=cliff <> 
> just for mapping an inclined bare rock surface, use natural 
> <https://wiki.openstreetmap.org/wiki/Key:natural>=bare_rock 
> <https://wiki.openstreetmap.org/wiki/Tag:natural%3Dbare_rock> instead.
> 
> " 
> 
> This is not what I see when I look at this mapped area, I agree that some 
> mapped cliffs here are really what should be considered a cliff but they are 
> lost in lots of wrongly mapped and not relevant ones. 
> 
> You might look at this as a example in many many more :
> 
> https://www.openstreetmap.org/#map=19/50.89893/14.28319 
> <https://www.openstreetmap.org/#map=19/50.89893/14.28319>
> 
> We are seeing it at level 19 and the density of cliffs is still crazy ! 
> 
> Or here : https://www.openstreetmap.org/#map=15/50.8791/14.3647 
> <https://www.openstreetmap.org/#map=15/50.8791/14.3647>
> 
> Could you tell me that all theses mapped cliffs really exists ? Or aren’t 
> they just « a significant drop in terrain and neither of them are close to 
> vertical » mapped as cliffs only looking at terrain model and that are 
> completely disconnected from the reality of the terrain ?
> 
> Regards,
> Vladimir
> 
> 
> 
>> Le 11 sept. 2019 à 00:17, Sarah Hoffmann > <mailto:lon...@denofr.de>> a écrit :
>> 
>> Hi,
>> 
>> On Fri, Sep 06, 2019 at 02:42:06PM +0200, Vladimir Vyskocil wrote:
>>> Around this area : https://www.openstreetmap.org/#map=16/50.9034/14.2763 
>>> <https://www.openstreetmap.org/#map=16/50.9034/14.2763> 
>>> <https://www.openstreetmap.org/#map=16/50.9034/14.2763 
>>> <https://www.openstreetmap.org/#map=16/50.9034/14.2763>> there is a 
>>> flagrant misuse and abuse of the usage of the natural=cliff tag. It is used 
>>> to map the iso altitude lines and not real cliff as stated in the WIKI :
>>> 
>>> A cliff <http://en.wikipedia.org/wiki/en:cliff 
>>> <http://en.wikipedia.org/wiki/en:cliff>> is a vertical or almost vertical 
>>> natural drop in terrain topography as it occurs for example in form of 
>>> coastal cliffs or escarpments. The face of the cliff usually consists of 
>>> bare solid rock but can occasionally also consist of clay, compacted sand, 
>>> ice or other solid materials.  
>> 
>> I know that area very well and I can assure you, that natural=cliff is no 
>> misuse
>> under this definition. The area is full of rock towers like those:
>> https://commons.wikimedia.org/wiki/File:20171124195DR_Lohmen_Basteiaussicht_zum_Sieberturm.jpg
>>  
>> <https://commons.wikimedia.org/wiki/File:20171124195DR_Lohmen_Basteiaussicht_zum_Sieberturm.jpg>
>> 
>> That's what you see on the map.
>> 
>>> I already removed the natural=cliff ways mapped by MichaOSM after asking 
>>

Re: [OSM-talk] Abuse of natural=cliff tag

[Vladimir Vyskocil]

Hello Sarah,

I read carefully your response and looked at the picture. I didn't travelled 
exactly at this place but will go there in October ! However I've already been 
in Český ráj 
<http://www.cesky-raj.info/en/contacts/bohemian-paradise-association/> that is 
not too far from there and where the terrain is similar in many aspects.
I still think that the usage of the tag is abused in this area…
You may read the description of this tag here :

https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff 
<https://wiki.openstreetmap.org/wiki/Tag:natural=cliff>

«  A cliff <http://en.wikipedia.org/wiki/en:cliff> is a vertical or almost 
vertical natural drop in terrain topography as it occurs for example in form of 
coastal cliffs or escarpments. The face of the cliff usually consists of bare 
solid rock but can occasionally also consist of clay, compacted sand, ice or 
other solid materials.» 


« 
When not to use
natural <https://wiki.openstreetmap.org/wiki/Key:natural>=cliff <> should not 
be used for ridges, i.e. crests where there is a significant drop in terrain to 
both sides and neither of them is close to vertical. Use natural 
<https://wiki.openstreetmap.org/wiki/Key:natural>=ridge 
<https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge> or natural 
<https://wiki.openstreetmap.org/wiki/Key:natural>=arete 
<https://wiki.openstreetmap.org/wiki/Tag:natural%3Darete> instead. Also do not 
use natural <https://wiki.openstreetmap.org/wiki/Key:natural>=cliff <> just for 
mapping an inclined bare rock surface, use natural 
<https://wiki.openstreetmap.org/wiki/Key:natural>=bare_rock 
<https://wiki.openstreetmap.org/wiki/Tag:natural%3Dbare_rock> instead.

" 

This is not what I see when I look at this mapped area, I agree that some 
mapped cliffs here are really what should be considered a cliff but they are 
lost in lots of wrongly mapped and not relevant ones. 

You might look at this as a example in many many more :

https://www.openstreetmap.org/#map=19/50.89893/14.28319 
<https://www.openstreetmap.org/#map=19/50.89893/14.28319>

We are seeing it at level 19 and the density of cliffs is still crazy ! 

Or here : https://www.openstreetmap.org/#map=15/50.8791/14.3647 
<https://www.openstreetmap.org/#map=15/50.8791/14.3647>

Could you tell me that all theses mapped cliffs really exists ? Or aren’t they 
just « a significant drop in terrain and neither of them are close to vertical 
» mapped as cliffs only looking at terrain model and that are completely 
disconnected from the reality of the terrain ?

Regards,
Vladimir



> Le 11 sept. 2019 à 00:17, Sarah Hoffmann  a écrit :
> 
> Hi,
> 
> On Fri, Sep 06, 2019 at 02:42:06PM +0200, Vladimir Vyskocil wrote:
>> Around this area : https://www.openstreetmap.org/#map=16/50.9034/14.2763 
>> <https://www.openstreetmap.org/#map=16/50.9034/14.2763> there is a flagrant 
>> misuse and abuse of the usage of the natural=cliff tag. It is used to map 
>> the iso altitude lines and not real cliff as stated in the WIKI :
>> 
>> A cliff <http://en.wikipedia.org/wiki/en:cliff> is a vertical or almost 
>> vertical natural drop in terrain topography as it occurs for example in form 
>> of coastal cliffs or escarpments. The face of the cliff usually consists of 
>> bare solid rock but can occasionally also consist of clay, compacted sand, 
>> ice or other solid materials.  
> 
> I know that area very well and I can assure you, that natural=cliff is no 
> misuse
> under this definition. The area is full of rock towers like those:
> https://commons.wikimedia.org/wiki/File:20171124195DR_Lohmen_Basteiaussicht_zum_Sieberturm.jpg
> 
> That's what you see on the map.
> 
>> I already removed the natural=cliff ways mapped by MichaOSM after asking him 
>> to fix this but without response the changeset comment was : 
>> 
>> "Felsen, Riffe, Topografie nach GeoSachsen digitale 
>> Geländemodellhoehenlinien 2.5m, digitales Geländereliefmodell, DTK10, 
>> topografische Karte”
>> 
>> For example this changeset : 
>> https://www.openstreetmap.org/changeset/66373825#map=15/50.9016/14.3093 
>> <https://www.openstreetmap.org/changeset/66373825#map=15/50.9016/14.3093>
>> 
>> It say that it used a 2.5m topographic map to map all these false cliffs in 
>> this area, he was mapping the topography (MNT) and this is forbidden in OSM.
> 
> You missunderstood, he was mapping rock edges. A terrain model is more helpful
> for that task than arial imagery. We have permission to use the terrain model
> for OSM as far as I know.
> 
> I would kindly request that you reinstate deleted natural=cliffs for
> the moment. If you are still not convinced from the photo above that the
> tagging is correc

[OSM-talk] Abuse of natural=cliff tag

[Vladimir Vyskocil]

Hi !

Around this area : https://www.openstreetmap.org/#map=16/50.9034/14.2763 
 there is a flagrant 
misuse and abuse of the usage of the natural=cliff tag. It is used to map the 
iso altitude lines and not real cliff as stated in the WIKI :

A cliff  is a vertical or almost 
vertical natural drop in terrain topography as it occurs for example in form of 
coastal cliffs or escarpments. The face of the cliff usually consists of bare 
solid rock but can occasionally also consist of clay, compacted sand, ice or 
other solid materials.  

When not to use

natural =cliff <> should not 
be used for ridges, i.e. crests where there is a significant drop in terrain to 
both sides and neither of them is close to vertical. Use natural 
=ridge 
 or natural 
=arete 
 instead. Also do not 
usenatural =cliff <> just for 
mapping an inclined bare rock surface, use natural 
=bare_rock 
 instead. 

I already removed the natural=cliff ways mapped by MichaOSM after asking him to 
fix this but without response the changeset comment was : 

"Felsen, Riffe, Topografie nach GeoSachsen digitale Geländemodellhoehenlinien 
2.5m, digitales Geländereliefmodell, DTK10, topografische Karte”

For example this changeset : 
https://www.openstreetmap.org/changeset/66373825#map=15/50.9016/14.3093 


It say that it used a 2.5m topographic map to map all these false cliffs in 
this area, he was mapping the topography (MNT) and this is forbidden in OSM.

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

[OSM-talk-fr] Quand le plus est l'ennemi du raisonnable !

[Vladimir Vyskocil]

> On 31 Aug 2019, at 21:18, GarenKreiz  > wrote:
> 
> Bonsoir,
> 
> Pas sûr qu'il s'agisse d'erreurs ou de vandalisme car c'est semble-t-il un 
> parc national célèbre pour ses falaises de grès. Le mapping pourrait être 
> légitime si chaque falaise fait une dizaine de mètres de hauteur : ce type 
> d'information intéresse sûrement les grimpeurs pour mieux se repérer.


Clairement ici la densité des “falaises” serait beaucoup trop importante pour 
que cela soit possible, à la rigueur un way avec natural=cliff par gros rocher 
mais voila à quoi cela ressemble sur une petite partie de la zone :



> 
> Les photos du coin donnent envie d'aller y faire un tour pour vérifier la 
> topographie de la zone!

J’y vais fin octobre !

> 
> Cordialement
> 
>  Garenkreiz


Vladimir


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

Re: [OSM-talk-fr] Quand le plus est l'ennemi du raisonnable !

[Vladimir Vyskocil]

Merci pour le texte en allemand, je viens de l’envoyer en commentaire sur les 2 
changeset identifiés et en message privé, on va voir s’il y a une réaction.

Vlad.

> On 30 Aug 2019, at 21:14, osm.sanspourr...@spamgourmet.com wrote:
> 
> Le 30/08/2019 à 20:26, JB - jb...@mailoo.org  a 
> écrit :
> 
>> Il n’y aurait pas la "un peu" de détournement du tag natural=cliff 
>> (https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff 
>> ) ?
>>> 
>>> https://www.openstreetmap.org/#map=16/50.8899/14.3052 
>>> Peut-être, peut-être 
>>> pas. En tous cas, si problème il y a, ce serait aux Allemands de le 
>>> résoudre, une action à distance d'un autre pays sera probablement mal vue, 
>>> à juste titre il me semble. 
>> JB.
> Vladimir, comme toi, moi ou MichaOSM sont des contributeurs OSM, s'il existe 
> des règles spécifiques à un pays à respecter ici on a du vandalisme (création 
> de fausses falaises), ceci est anormal dans tout pays.
> 
> Je pourrais ajouter la densité trop élevée de nœuds dans les chemins.
> 
> Quant à la densité des "falaises", ici on est au niveau 19 
> . 
> Et non il n'y a pas de culture en terrasses (le tag ne serait pas le bon 
> d'ailleurs).
> 
> Donc pour lever un loup, on se fiche pas mal que ce soit fait par un Allemand 
> ou un non Allemand.
> 
> Tu remarqueras que je suggère au contributeur de corriger le problème 
> lui-même.
> 
> Jean-Yvon
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] Quand le plus est l'ennemi du raisonnable !

[Vladimir Vyskocil]

Salut !

Il n’y aurait pas la "un peu" de détournement du tag natural=cliff 
(https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff 
) ?

https://www.openstreetmap.org/#map=16/50.8899/14.3052 


Vlad.

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

Re: [OSM-talk-fr] Photos ESRI et Tahiti

[Vladimir Vyskocil]

Salut,

Merci pour cette info ! J’ai bien un compte Strava mais on dirait qu’il n’y en 
a même pas besoin :

http://strava.github.io/iD/#background=Bing=16.13/-149.49614/-17.59643 


Il y a assez peu de données sur la 2eme moitié du chemin mais mes modifications 
semblent pas si mauvaises.

Vladimir

> On 17 Mar 2019, at 18:36, jabali  wrote:
> 
> Salut,
> Si tu as un compte Strava tu peux utiliser les données High-res Global
> Heatmap dans josm
> https://wiki.openstreetmap.org/wiki/Strava#High-res_Global_Heatmap_in_JOSM
> 
> et affiner-corriger de façon encore plus précise ton itinéaire
> ex1
> [url=https://postimg.cc/xJzwmGFy][img]https://i.postimg.cc/xJzwmGFy/pic-1.jpg[/img][/url]
> ex2
> [url=https://postimg.cc/30QPFysM][img]https://i.postimg.cc/30QPFysM/pic-2.jpg[/img][/url]
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] Photos ESRI et Tahiti

[Vladimir Vyskocil]

Salut,

En préparation d’un voyage à Tahiti je suis allé voir l’état d’OSM la bas et 
notamment quelques randonnées, dont celle qui mène au Mont Aorai :

https://www.openstreetmap.org/?mlat=-17.6132=-149.4953#map=16/-17.6132/-149.4953
 


En comparant les différents fonds de carte j’ai constaté que presque tous 
semblaient assez décalés, parfois avec de mauvais raccord entre les dalles, 
comme Bing, Digital Globe.
J’ai aussi constaté que les données d'élévation SRTM sont complètement fausses 
dans le centre de l’ile ! Comme si des trous dans les données avaient été 
lissées et ont fait disparaitre des crêtes et des sommets…

Voila ce que l’on peut voir sur OpenTopoMap :

https://opentopomap.org/#map=15/-17.60748/-149.49474

Du coup j’ai l’impression que les erreurs sur la plupart des images de fond de 
carte proviennent des mauvaises données SRTM qui a fait faire n’importe quoi 
pour l’ortho-rectification des photos !
Mais j’ai ensuite testé les images ESRI mondiale et cela semble être très bon 
dans cette partie de l’ile ! J’ai du coup corrigé le sentier qui est sensé 
suivre les crêtes jusqu’au Mont Aorai.
Quelqu’un à de l’expérience sur cette partie du globe ?

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

[OSM-talk-fr] Utilisation du tag 'name' avec les langues régionales

[Vladimir Vyskocil]

Bonjour,

Suite aux actions de certaines communautés régionales comme par exemple 
Toulouse qui est devenu Tolosa/Toulouse par ce qu’un fervent adepte de 
l’occitan l'à décidé un jour… J’ai regardé et commencé à corriger les erreurs 
rapportées par Osmose sur l’utilisations des tags name et name:fr, qui doivent 
être identiques pour la France dans la règle correspondante…
Mais je commence à m’attirer les foudres de certains au pays basque et je 
voulais vous faire part de ma dernière réponse. J’ai répondu avec mes 
connaissances du projet mais je peux me tromper et cela a pu évoluer ces 
derniers temps ? Qu’en pensez vous ?

Bonjour,

On va continuer en français : Il y a plusieurs points dans votre message 
auxquels je voudrais répondre : 

- OpenStreetMap est une base cartographique et pas une carte, il y a autant de 
rendu possible que l'on désire, celui du site openstreetmap.org en est un et il 
est international essentiellement destiné aux contributeurs internationaux du 
projet. Il existe des rendus plus spécialisés par exemple sur openstreetmap.fr 
qui se focalise sur la communauté française ou un site qui prend en compte les 
noms régionaux de Bretagne et qui est géré par la communauté bzh. 

- Les règles sur l'utilisation des tags des objets de la base est établie plus 
ou moins par consensus par la communauté internationale, plus particulièrement 
pour les tags name, name:xxx, et autres... pour le tag name la règle établie 
est qu'il contient le nom dans la langue ou les langues officielles du pays 
correspondant, par exemple en Belgique c'est le français et le flamand et les 
valeurs du tag sont nom_dans_la_langue1 / (ou -, ...) nom_dans_la_langue2. En 
france il n'y a qu'une seule langue officielle et c'est le français et des 
langues régionales comme le basque, l'occitan, le breton, le niçois par chez 
moi,… 

- Il y a de plus en plus d'anarchie dans l'utilisation du tags "name" en 
France, on commence a voir des choses comme Tolosa/Toulouse parce que quelqu'un 
dans la communauté occitane a décidé que cela lui plaisait mieux comme ça ou 
par revendication... Idem pour la communauté basque, que je respecte par 
ailleurs (et c'est un très beau pays que j'aime beaucoup, autant coté français 
qu'espagnol). 

- D'ailleurs vous parlez de villages avec une signalisation bi-linguale ou je 
vous le concède le tag name peut recevoir les noms dans les deux langues (en se 
mettant d'accord sur le séparateur, l'ordre,... pour que cela soit uniforme ce 
qui n'est pas le cas actuellement), mais pour des villes comme Bayonne, 
Biarritz,... je ne suis pas d'accord car ce n'est pas jusqu’à preuve du 
contraire ce que l'on voit sur le terrain (je parle de panneaux officiels)

 - En ce qui concerne l'outil Osmose, il compile un grand nombre de règles 
acceptées par au moins la communauté française et parcours la base pour trouver 
les erreurs et permettre de les corriger, c'est le reflet des règles en 
vigueur. S'il est légitime d'en changer certaines, il est nécessaire d'entamer 
le discours pour obtenir un consensus avec la communauté FR, le mieux est d'en 
discuter sur la liste OSM française 
(https://lists.openstreetmap.org/listinfo/talk-fr 
) - Pour la promotion de la 
langue basque vous pouvez à l'instar d'autres communautés régionales comme les 
bretons par exemple monter un site qui affichera correctement la carte avec les 
options que vous aurez choisi, par exemple une combinaison des tags name:eu et 
name:fr ou seulement name:eu ou au choix,...

Cordialement, Vladimir (français d'adoption)

Hi Vlad,

I have followed the discussion on this changeset 
. Can you explain what exactly 
is the problem ? Following your link I find a "Default and local language name 
not the same" issues ... (Albeit, I don't understand why this should be an 
issue, since as far as I understand it, different tags are meant to reference 
different things...) We have bilingual usage here in north basque country, as 
you enter all our villages you will find a bilingual (french - basque) 
signalisation. So I don't understand why we could not put both basque and 
french name in the "name=" tag and have each language separated in their 
respective tag, i.e. "name:fr=" and "name:eu=*" wich is what I did. So just 
because Osmose don't like it, seems not a raisonnable argument for me. Looking 
to read more from you,

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

Re: [OSM-talk-fr] Des choses très étranges en Chine

[Vladimir Vyskocil]

> On 3 avr. 2016, at 13:04, Frédéric Rodrigo <fred.rodr...@gmail.com> wrote:
> 
> Bonjour,
> 
> Il existe des scripts pour annuler des changesets.
> http://wiki.openstreetmap.org/wiki/Change_rollback
> http://wiki.openstreetmap.org/wiki/Revert_scripts

Merci pour les pointeurs mais j’ai déjà essayé le Reverter plugin pour JOSM qui 
est cité et il n’y arrive pas car l’API refuse de charger autant de nodes, j’ai 
peur que cela soit pareil pour les autres scripts...

> 
> Tu pense que ces erreurs sont involontaires ou pas ?

Je me demande bien, soit c’est volontaire soit c’est un bug dans un outil 
utilisé par cette personne

> 
> Frédéric.

Vladimir

> 
> 
> Le 03/04/2016 11:25, Vladimir Vyskocil a écrit :
>> Bonjour,
>> 
>> Je suis tombé sur des choses très bizarres en Chine, l’utilisateur 
>> https://www.openstreetmap.org/user/Rebecca114 a crée 5 noeuds sans aucun 
>> tag exactement superposés en plusieurs points de la Chine, par exemple ce 
>> changeset :
>> 
>> https://www.openstreetmap.org/changeset/36351034
>> 
>> Le problème c’est que je n’arrive ni a charger ces zone dans JOSM, ni a 
>> faire un revert avec JOSM, ni a utiliser iD !
>> Une idée pour corriger ça ?
>> 
>> Vladimir.
>> 
>> 
>> 
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


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

[OSM-talk-fr] Des choses très étranges en Chine

[Vladimir Vyskocil]

Bonjour,

Je suis tombé sur des choses très bizarres en Chine, l’utilisateur 
https://www.openstreetmap.org/user/Rebecca114 
 a crée 5 noeuds sans aucun 
tag exactement superposés en plusieurs points de la Chine, par exemple ce 
changeset :

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


Le problème c’est que je n’arrive ni a charger ces zone dans JOSM, ni a faire 
un revert avec JOSM, ni a utiliser iD !
Une idée pour corriger ça ?

Vladimir.

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

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vladimir Vyskocil]

Bon à y regarder de plus prêt on dirait que ce sont les routes qui ont été 
malmenées dans ce coin et que les arbres sont plutôt aux bons emplacements !

 On 03 Aug 2015, at 11:45, Vladimir Vyskocil vladimir.vysko...@gmail.com 
 wrote:
 
 C’est dangereux de rouler sur le Boulevard René Cassin par exemple ;-)
 
 http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884
  
 http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884
 
 Je suppose que ce sont des arbres d’un import précédent ?
 
 Vlad.
 
 On 01 Aug 2015, at 19:02, Vincent Frison vincent.fri...@gmail.com 
 mailto:vincent.fri...@gmail.com wrote:
 
 Alors j'ai rajouté la petite vérification pour savoir si l'arbre importé est 
 à l'intérieur d'un bâtiment ou pas. Cela permet donc d'avoir un fichier à 
 part avec les arbres posant problème. 
 
 Voici les dernières stats:
 Total of makable imports: 30246
 Total of non makable imports: 275
 Matching area radius: 5.0
 Total of created trees: 29430
 Total of updated trees: 816
 Total of created or updated trees: 30246
 Total of multi matching trees: 306
 
 Il y a donc 275 arbres posant problème qu'on peut en gros diviser en 2 
 catégories:
 - les arbres qui sont collés à un bâtiment mais qui se retrouvent à 
 l'intérieur comme c'est le cas pour la basilique Notre Dame (difficile de 
 dire qui a raison ou tort). Il y en a environ une bonne quarantaine comme 
 ça...
 - les arbres qui sont à l'intérieur d'un bâtiment parce que celui ci est mal 
 fait dans OSM (ex: bibliothèque bien plus grande que la réalité et qui 
 englobe son parc, ou bâtiment d'école simplifié ne laisse plus de place à sa 
 cour interne, etc.). 
 
 C'est du coup un bon test pour voir des corrections à faire (une sorte de 
 mini osmose ;p), je conserve donc ce fichier pour faire certaines 
 corrections plus tard et pouvoir ensuite importer certains arbres 
 normalement, merci Jérôme pour l'idée.
 
 En attendant je compte bien uploader les 30 246 autres arbres qui sont hors 
 bâtiments.. sauf si évidemment vous me dites que cela entraînera forcement 
 un revert et mon bannissement du forum sur les 3 prochaines générations..
 
 
 
 
 Le 31 juillet 2015 00:00, Vincent Frison vincent.fri...@gmail.com 
 mailto:vincent.fri...@gmail.com a écrit :
 Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr 
 mailto:jseigneuret-...@yahoo.fr a écrit :
 Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des 
 bâtiments aussi donc qui a raison? 
 
 Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien être 
 possible de faire comme sous n'importe quel SIG un tag intermédiaire 
 note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre 
 dans un fichier *.osm et à retoucher au fur et à mesure pour faire 
 l'intégration en semi-auto par exemple par type d'alerte.
 
 C'est plus simple et au moins il n'y a plus d’ambiguïté. 
 
 Le plus simple c'est encore d'ignorer purement et simplement tous les 
 éléments posant problème.
 
 Mais je trouve que c'est une bonne idée de garder ces éléments dans un 
 fichier à part.. histoire de ne rien lâcher ! ;p 
 
 Je ferai ça ce WE..
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr
 

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

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vladimir Vyskocil]

C’est dangereux de rouler sur le Boulevard René Cassin par exemple ;-)

http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884
 
http://www.openstreetmap.org/?mlat=43.66954mlon=7.21884#map=19/43.66954/7.21884

Je suppose que ce sont des arbres d’un import précédent ?

Vlad.

 On 01 Aug 2015, at 19:02, Vincent Frison vincent.fri...@gmail.com wrote:
 
 Alors j'ai rajouté la petite vérification pour savoir si l'arbre importé est 
 à l'intérieur d'un bâtiment ou pas. Cela permet donc d'avoir un fichier à 
 part avec les arbres posant problème. 
 
 Voici les dernières stats:
 Total of makable imports: 30246
 Total of non makable imports: 275
 Matching area radius: 5.0
 Total of created trees: 29430
 Total of updated trees: 816
 Total of created or updated trees: 30246
 Total of multi matching trees: 306
 
 Il y a donc 275 arbres posant problème qu'on peut en gros diviser en 2 
 catégories:
 - les arbres qui sont collés à un bâtiment mais qui se retrouvent à 
 l'intérieur comme c'est le cas pour la basilique Notre Dame (difficile de 
 dire qui a raison ou tort). Il y en a environ une bonne quarantaine comme 
 ça...
 - les arbres qui sont à l'intérieur d'un bâtiment parce que celui ci est mal 
 fait dans OSM (ex: bibliothèque bien plus grande que la réalité et qui 
 englobe son parc, ou bâtiment d'école simplifié ne laisse plus de place à sa 
 cour interne, etc.). 
 
 C'est du coup un bon test pour voir des corrections à faire (une sorte de 
 mini osmose ;p), je conserve donc ce fichier pour faire certaines corrections 
 plus tard et pouvoir ensuite importer certains arbres normalement, merci 
 Jérôme pour l'idée.
 
 En attendant je compte bien uploader les 30 246 autres arbres qui sont hors 
 bâtiments.. sauf si évidemment vous me dites que cela entraînera forcement un 
 revert et mon bannissement du forum sur les 3 prochaines générations..
 
 
 
 
 Le 31 juillet 2015 00:00, Vincent Frison vincent.fri...@gmail.com 
 mailto:vincent.fri...@gmail.com a écrit :
 Le 30 juillet 2015 23:24, Jérôme Seigneuret jseigneuret-...@yahoo.fr 
 mailto:jseigneuret-...@yahoo.fr a écrit :
 Oui pour empêcher l'import mais on n'est pas à 15 cm sur le placement des 
 bâtiments aussi donc qui a raison? 
 
 Il faudrait genre un pré-filtre. Si tu fais ça sous JOSM il doit bien être 
 possible de faire comme sous n'importe quel SIG un tag intermédiaire 
 note=FIXME et tu n'intègres que ceux sans alerte. Les autres c'est à mettre 
 dans un fichier *.osm et à retoucher au fur et à mesure pour faire 
 l'intégration en semi-auto par exemple par type d'alerte.
 
 C'est plus simple et au moins il n'y a plus d’ambiguïté. 
 
 Le plus simple c'est encore d'ignorer purement et simplement tous les 
 éléments posant problème.
 
 Mais je trouve que c'est une bonne idée de garder ces éléments dans un 
 fichier à part.. histoire de ne rien lâcher ! ;p 
 
 Je ferai ça ce WE..
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice

[Vladimir Vyskocil]

Bonjour !

Je suis un contributeur de la région, j’ai par exemple intégré le bâti du 
cadastre sur Nice et pas mal de communes alentours,...
Mon opinion sur l’import massif d’arbres “quelconques” est assez négatifs pour 
plusieurs raisons :

- quid de la maintenance a long terme car le sujet ne semble pas passionner 
beaucoup de monde
- le rendu OSM “standard” n’est pas bon a mon avis, c’est trop chargé, on 
dirait que la carte a chopé la varicelle ;-)
- je comprend l’intérêt que cela peut avoir pour certains domaine d’activité 
d’avoir ces données mais pour la grande majorité je ne vois pas… 
- cela dilue et cache l’information sur les arbres “remarquables” qui eux 
méritent d’apparaitre sur le rendu généraliste
- quand j’importe les données OSM pour la France entière dans mon logiciel 
utilisant libosmscout qui compile tout ça dans une base binaire de 4.5Go (avec 
les lignes de niveau à intervalle de 10m) je dois filtrer les arbres car sinon 
l’import explose à cause d’une trop forte concentration d’un même type de noeud 
(les arbres) dans certaines zones !

Cordialement,
Vlad (https://www.openstreetmap.org/user/Vlad 
https://www.openstreetmap.org/user/Vlad)

 On 28 Jul 2015, at 00:17, Vincent Frison vincent.fri...@gmail.com wrote:
 
 Le 27 juillet 2015 22:46, Christian Quest cqu...@openstreetmap.fr 
 mailto:cqu...@openstreetmap.fr a écrit :
 Le 27/07/2015 01:01, osm.sanspourr...@spamgourmet.com 
 mailto:osm.sanspourr...@spamgourmet.com a écrit :
 Mais c'est l'arbre qui cache la forêt : je vois que des rues de Nice n'ont 
 pas de nom (http://www.openstreetmap.org/way/156776064 
 http://www.openstreetmap.org/way/156776064). Il semble pourtant y avoir 
 des habitants, il y a même des numéros sur les bâtiments 
 (http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.71235/7.27541 
 http://tile.openstreetmap.fr/%7Ecquest/leaflet/bano.html#19/43.71235/7.27541).
  Alors un nom de rue, de résidence ?
 
 Non, pas de numéros sur les bâtiments dans OSM... ils seraient en vert sur le 
 rendu BANO.
 Ce qui est en bleu c'est le cadastre (avec rapprochement OSM), en jaune c'est 
 l'opendata et en gris la BAN.
 
 Oui des noms de rues manquent encore sur Nice... et bien qu'il n'y ait pas de 
 priorité à mapper tel ou tel type d'info avant une autre, c'est quand même 
 symptomatique d'une zone avec une communauté pas très active surtout par 
 rapport à la densité de population. 
 Si je veux aller à Nice, la carte me sert avant tout à trouver les rues. Les 
 arbres, ça vient après, seulement après.
 
 PSS donne des infos pertinentes sur des lieux remarquables, comme 
 http://structurae.net/ http://structurae.net/.
 Relier ces données à OSM me semble bien plus intéressant, pertinent.
 La notion de valeur ajoutée me semble très importante.
 
 Bien sûr les arbres importés ne vont pas décourager une communauté locale, 
 mais importer ces données sans se mettre en relation avec cette communauté ne 
 va pas dans le bon sens pour la développer.
 
 Je suis bien d'accord mais à vrai dire c'est un peu ce que je pensais faire 
 en créant ce thread au titre plutôt évocateur. Malheureusement pas beaucoup 
 de niçois se sont manifestés...
 
 En tout cas j'ai essayé de contacter les 3 contributeurs qui avaient déjà 
 rajoutés des arbres sur Nice:
 - un seul m'a répondu pour l'instant et il n'est plus sur la région (tiens ça 
 me rappelle mon exemple, qui va maintenant s'occuper des arbres qu'il a créé 
 ? :p)
 - un autre ne m'a pas répondu mais au vu de ses contributions il n'est plus 
 sur la région non plus  !
 - l'autre par contre est encore dans les parages, j'ai donc encore un peu 
 d'espoir de pas être tout à fait seul
 
 Après c'est sûr que c'est pas les seuls (j'essayerai d'autres contributeurs 
 récemment actifs) mais ça montre qu'effectivement il n'y a pas une énorme 
 activité sur la région, ce qui est effectivement surprenant vu la densité de 
 population.. 
 
 OSM est aussi un projet très social... il faut un petit peu de temps pour 
 intégrer aussi cet aspect. 
 Il m'a fallu du temps pour prendre du recul avec la technique et pour 
 comprendre cette dimension... je ne pense pas être le seul. Relire nos 
 premières interventions sur talk-fr est assez instructif de ce point de vue !
 
 Personnellement ça m'a semblé assez clair dès le début et c'est d'ailleurs 
 pour ça que je n'ai pas hésité dès le début à communiquer et demander de 
 l'aide sur mes imports..
  
 Il y a plein de dev à faire, mais surtout pour mettre à disposition des 
 non-dev des outils de plus en plus pratiques, ergonomiques, rapides, 
 efficaces pour viser le meilleur rapport temps passé/valeur ajoutée et 
 utilisables par le public le plus large.
 
 C'est sur que c'est primordiale, je trouve d'ailleurs que l'éditeur iD est 
 assez génial de ce point de vue là.. 
 
 Bon en tout cas ça ne résout pas vraiment mon problème pour savoir si je peux 
 ou pas envoyer mon import sur le serveur.. en tant que chef tu ne pourrais 
 pas me donner un 

Re: [OSM-talk-fr] Nice, rajouter une place

[Vladimir Vyskocil]

 On 31 Mar 2015, at 12:06, Jérôme Seigneuret jseigneuret-...@yahoo.fr wrote:
 
 @Brice: Par contre je viens de voir que tu parlais de  highway=residential 
 pour une place. Il me semble que sur la page du tag highway 
 http://wiki.openstreetmap.org/wiki/Key:highway ce couple de clé valeur 
 n'est a exploiter qu'en linéaire.
 
 Il n'y a que highway=service et highway=pedestrian qui accepte des tracés 
 fermés et dans le cas de la valeur pedestrian il faut bien mettre area=yes en 
 plus car par défaut c'est un tracé ouvert

Si je ne me goure pas, j’ai vu passer assez récemment un changement qui 
étendait la prise en compte d’autres types de highway en temps que surface pour 
le rendu “OSM standard”. A vérifier.

 
 Pour service on ne peut pas avoir plus de détails car service=* n'accepte que 
 du tracé ouvert à moins de compléter les règles.
 
 
 
 
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] Vous avez dit taguer pour le rendu ?

[Vladimir Vyskocil]

Celui la ne doute de rien, utiliser deux bouts de piste d’aviation pour faire 
une croix et un locality “crash site of Germanwings…” pour marquer le supposé 
site du crash, faux en plus, il me semble… :

http://www.openstreetmap.org/changeset/29724802 
http://www.openstreetmap.org/changeset/29724802

J’ai supprimé.

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

Re: [OSM-talk-fr] JOSM et son scan de disque - J'en ai ma claque !!!

[Vladimir Vyskocil]

On 16 août 2014, at 22:18, Christian Quest cqu...@openstreetmap.fr wrote:

 J'utilise JOSM sous OSX (10.6 et 10.9) et je n'ai pas remarqué ce 
 comportement.

Oui pareil j'utilise JOSM sous OSX 10.9, le package disponible sur le site qui 
permet d'installer JOSM comme une application normale et tout fonctionne très 
bien.
Pour la version de java j'ai ceci :

$ java -version
java version 1.7.0_51
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) 

 
 Par contre aucun antivirus pour moi sur mes Mac depuis l'abandon de 
 Disinfectant (en juin 1997).

Pas d'antivirus non plus.

Vlad.

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

Re: [OSM-talk-fr] effacement volontaire de radar

[Vladimir Vyskocil]

On 3 août 2014, at 12:42, Éric Gillet fear.hardcore+...@gmail.com wrote:

 Il est mappé également ici, mais il manque le noeud to dans la relation 
 enforcement

J'ai complété la relation avec un noeud to et effacé l'autre radar qui était 
taggué de manière quelque peu fantaisiste.

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

Re: [OSM-talk-fr] Améliorer GPS en ville sans connexion data?

[Vladimir Vyskocil]

Bonjour,

On 8 janv. 2014, at 01:09, Shohreh codecompl...@free.fr wrote:

 Bonjour
 
 À l'expérience, le GPS de mon smartphone Android (Galaxy Nexus) ne
 fonctionne quasiment pas en ville à l'étranger à cause de l'absence de
 connexion data (data roaming).
 
 Il ne fonctionne que lorsque je me trouve en extérieur dans une zone sans
 aucun bâtiment. J'imagine que les immeubles empêchent d'obtenir des signaux
 de différents satellites.
 
 Passer du Android standard à Cyanogenmod n'a rien changé sur ce point.
 
 Y a-t-il un moyen de contourner ce problème sans activer le data roaming et
 faire exploser ma note de communication?

J'avais remarqué avec mon iPhone qu'il suffit d'activer brièvement le data 
roaming pour effectuer un premier fix GPS puis ensuite on peut le couper et 
cela continue de fonctionner.
J'avais fait cette expérience en arrivant en Guadeloupe ou tant que je n'avais 
pas fait cette manipulation il était impossible au téléphone de se géolocaliser.

 
 Merci.
 

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

Re: [OSM-talk-fr] Vaincre les zones blanches

[Vladimir Vyskocil]

Je viens de lire cet article qui traite d'un sujet assez proche :

Level of Detail Inconsistencies in #OSM by Guillaume Touya
http://utpjournals.metapress.com/content/j846187vj7258101/fulltext.pdf

il y a même des exemple d'application dans OSM.

Vlad.



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

Re: [OSM-talk-fr] Le rendu 3D des terrains de sport...

[Vladimir Vyskocil]

Amazing, il pleut même en 3D comme pour de vrai ici !

http://map.f4-group.com/#lon=7.0603539lat=43.6205892zoom=18camera.theta=54.242

Et oui il y a une piscine en forme de raquette de Tennis pour de vrai :-)

Vlad.



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

Re: [OSM-talk] Crossroad names

[Vladimir Vyskocil]

I think it's time to switch to the tagging list !

The tagging scheme that seems preferred in this discussion is the following :

- simple named junctions : use junction=yes and name=*
- complex named junctions with several lanes crossing a different points :
two propositions : 
- use a relation { type=junction, name=*,  junction role,...} 
referencing all the crossing points between the lanes
- use a place { tag=junction or crossroads, name=* } on a area 
englobing the crossing points

All right ? What are your opinions on this ?

Vlad.


On 27 mars 2013, at 00:22, Satoshi IIDA nyamp...@gmail.com wrote:

 highway=traffic_signals + name=* are now also visible:
 Great!
 
 traffic_lights on complex crossroads
 Area or Relation
 I prefer to use relation.
 I'm afraid of effects to routing topology when signals or roundabouts
 are written as an area.
 
 As theory, the names of Japanese traffic signals are given to each
 signals, not to a junction.
 (and basically, the signals on a same junction has same names)
 
 
 
 2013/3/27 Christian Quest cqu...@openstreetmap.fr:
 highway=traffic_signals + name=* are now also visible:
 http://tile.openstreetmap.fr/?lon=139.71686lat=35.61534zoom=18
 
 You'll see that adding names to traffic_lights on complex crossroads
 causes the same name to be rendered multiple times in some places:
 http://tile.openstreetmap.fr/?lon=139.71825lat=35.61857zoom=18
 
 A better tagging scheme seems necessary as one thing should be in
 the database just once.
 
 If we could avoid relations and use either the junction=yes or a
 place=junction/crossroad (place name are usually meant to be rendered
 that's why I'm thinking about it).
 
 Think also about Nominatim... place=* makes more sense for that purpose.
 
 
 2013/3/25 Vladimir Vyskocil vladimir.vysko...@gmail.com:
 
 And there are more than 7000 nodes with highway=traffic_signals and name=*
 in Tokyo and its suburbs !
 Another country, another solution for the same tagging problem.
 
 Vlad.
 
 --
 Christian Quest - OpenStreetMap France
 Synthèse du Week-end SOTM-FR à Lyon : 
 http://openstreetmap.fr/synthese-sotmfr
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 
 
 
 -- 
 Satoshi IIDA
 mail: nyamp...@gmail.com
 twitter: @nyampire
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Crossroad names

[Vladimir Vyskocil]

 That's how it is I'm afraid, and that is a good example.  I'd suggest that 
 node needs an additional tag - junction=yes - as described in the wiki to 
 make it very clear.  It should also be merged with the node at the 
 intersection of the two ways that actually form the crossroads.
 

But how to deal with complex crossroads where there's not a single point of 
junction, but many (oneway or not) lanes crossing at different points ?
A relation with type=junction referencing all the crossing points and carrying 
the name of the whole crossroad ?

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

Re: [OSM-talk] Crossroad names

[Vladimir Vyskocil]

About crossroad names in Japan, I contributed quite a lot in Tokyo for 
remapping after odbl clean up and recently. I'm french and I'm doing armchair 
mapping but I'll visit Tokyo in june and this is my motivation to fix and 
upgrade what I can do from here. I've also made a iOS application using OSM 
data for travel needs.
I've seen several practical solutions for crossroad names used there, but none 
of them seems the right solution. They have the merit to exists and I think 
it's time to look at them and find a consensus, then render this very needed 
information in those area !
Here are some samples of what can be found :

- Here : http://www.openstreetmap.org/browse/node/31254333, the 
highway=traffic_signals (both of them) have been tagged with the name of the 
crossing.There are lot of them. It's not the right solution for this problem 
because the information is duplicated accross several traffic_signals and 
crossing can have a name despite there is no traffic_signals...
- I thought I've seen highway=crossing with name tag but can't find any with 
overpass API... perhaps I just read someone talking about this possibility

Overpass XAPI call for highway=traffic_signals with names : 
http://overpass-turbo.eu/?q=PCEtLQpUaGlzIHF1ZXJ5IGxvb2vEiGZvciBub2Rlcywgd2F5xIhhbmQgcmVsYXRpb27EiAp3aXRoIMS0ZSBnaXZlbiBrZXkuCkNoxJFzxLh5b3XEl8SoxLrEriDEpMSmxIZ0xLZoxLhSdcS-YnV0dMWQYWJvxLwhCsSCPgp7e8WAeT3EhmdoxKB5fX3FqXt2YWzEiz10cmFmZmljX3NpZ27FuXPFtAo8b3NtLXNjcmlwxZXFi3RwxZ09ImpzxK4ixaggIDzFmsStbsaixqPGpMSKxIzEjnR5cGXGnMSZxJvGoQrGqsaqPGhhcy1rdsS_xpzFqsWsxbQiIHbHgsW3xbnEi8eFL8apxrjGusa8xr7HgGvGs2FtZSLHjsa3xrjGpGLFongtxqzEjSDFqsefb3jFtMebx5Avx6N5xqk8L8amxK7HsHDGlG7FlW3EmsayIsWiZHnHmsewxKhjxYzFiMS2xrDHvGRvd27IgcecPMe2ace4IMe6xJvGnHPFgGxlxZ_Ijcebx7HGjsaQxpLGlMaWPgc=CC313d6v3MR

Regards,
Vlad.

On 24 mars 2013, at 21:29, Hans Schmidt z0idb...@gmx.de wrote:

 Am 24.03.2013 19:28, schrieb Martin Koppenhoefer:
 this is a case where you would need the feature (e.g. also for custom
 subway signs, road colors, highway shields etc. by
 country/city/region/etc.)
 
 Actually if I think about it, the feature is rather a must-have in some
 future version:
 
 Different signs for temples, schools, parking lots, cementaries etc.
 Everything where something culturally or linguistical plays a role. I
 wouldn’t even dare to guess how much stuff there is which is better to
 distinguish from country to country.
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Crossroad names

[Vladimir Vyskocil]

On 25 mars 2013, at 17:48, Christian Quest cqu...@openstreetmap.fr wrote:

 Here is a quick and dirty rendering on the junction=yes + name=* tags
 that will make visible the 1800+ nodes overpass found mostly in Korea:
 
 http://tile.openstreetmap.fr/?zoom=17lat=37.40505lon=127.12573

And there are more than 7000 nodes with highway=traffic_signals and name=* in 
Tokyo and its suburbs !
Another country, another solution for the same tagging problem.

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

Re: [OSM-talk-fr] Rendu des terrains de sport

[Vladimir Vyskocil]

 Pour les vergers je suis plus circonspect. Sur le terrain a part avoir
 le nez de dessus pas grand monde est capable de dire ce qui est
 cultivé dans telle ou tel verger, et je pense que tout le monde s'en
 foute, Coller sur un fond de carte générique la nature des fruit
 cultivé me semble pas tres pertinente, sauf si in situ et de loin on
 peut a l'oeil disserné facilement un champ d'olivier, d'un champ de
 pommier, d'un champ de mirabellier. Que l'info soit dans la base c'est
 compréhensible, y a sûrement des gens qui en auront l'utilité, mais de
 la a coller l'info sur un fond de carte générique je ne vois pas
 l’intérêt. Il serait plus utile si cela avait été possible de
 reproduire l'orientation des rangée d'arbre, qui elle correspond a
 quelques choses de clairement visible sur le terrain par exemple, en
 pratique on a pas cette info et on ne peut pas la déduire non plus
 donc plouf.

Cela dépend de ce que l'on appel rendu générique, si c'est le rendu a 
destination des contributeurs qui permet de voir que notre précédente 
contribution semble ok parce qu'elle a été comprise par le rendu de 
référence, alors oui il y a un intérêt pour en représenter un maximum. 
Attention je ne parle pas ici de tagguer pour le rendu, mais d'une aide 
visuelle qui permet de s'interroger quand on obtient pas un rendu attendu.
Quelques exemples : problemes dans les relations multipolygone qui font qu'un 
landuse ne s'affiche pas, route de bus qui n'est pas vues car incorrectement 
tagguée,


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


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

[OSM-talk-fr] Petit dessins dans OSM

[Vladimir Vyskocil]

Cela semble correspondre à quelque chose sur le terrain mais ce ne sont 
clairement pas des wall  et des hedge...

http://www.openstreetmap.org/?lat=35.613429lon=139.835213zoom=18layers=M

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

Re: [OSM-talk-fr] Avis aux golfeurs...

[Vladimir Vyskocil]

On 21 mars 2013, at 20:23, Christian Quest cqu...@openstreetmap.fr wrote:

 Et hop: 
 http://tile.openstreetmap.fr/?lon=2.44923lat=48.83113zoom=17layers=B0
 
 Je suis preneur de permaliens où le rendu serait à côté de la plaque...

ici : 
http://tile.openstreetmap.fr/?lon=7.05272lat=43.57609zoom=19layers=B0 ?

 
 -- 
 Christian Quest - OpenStreetMap France
 Synthèse du Week-end SOTM-FR à Lyon : 
 http://openstreetmap.fr/synthese-sotmfr
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Tsunami au Mt St Michel ???

[Vladimir Vyskocil]

On 20 mars 2013, at 16:23, Philippe Verdy verd...@wanadoo.fr wrote:

 Certainement un trait de ligne de côte qui a été brisé à un moment donné.
 
 Ce n'est pas la première fois que cela se produit, on l'a vu pendant
 des mois à la pointe de la Bretagne, à cause d'un fichier de ligne de
 côte importé dans Mapnik et non vérifié avant l'import.
 
 Bref vérifier la continuité des natural=coastline.

Le trait de cote natural=coastline entourant le Mont St Michel semble ok, il 
est bien fermé en tout cas, le validateur de JOSM ne rale pas (il rale si on 
ouvre le way correspondant)



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

Re: [OSM-talk-fr] Nommer les élément physique du relief, massif, vallée, plaine, plateau?

[Vladimir Vyskocil]

On 15 mars 2013, at 08:55, Romain MEHUT romain.me...@gmail.com wrote:

 
 En s'inspirant de http://alpha.map1.eu? Un rendu vraiment très chouette 
 comparable à France Topo!

La fameuse carte avec la mer True ;-)


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

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

Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)

[Vladimir Vyskocil]

Le drapeau c'est plutôt plutôt pour les ambassades, non ?
 
On 14 mars 2013, at 09:46, Francescu GAROBY windu...@gmail.com wrote:

 Pour le symbole de la façade, c'est vrai que c'est parlant, mais il lui 
 manque une précision, que le drapeau a le mérite d'avoir : les couleurs du 
 pays concerné.
 
 On peut alors imaginer plusieurs solutions possibles :
 * une façade coloré des couleurs du drapeau (compliqué à faire, et peut-être 
 pas lisible) ;
 * une façade + le drapeau (trop chargé, sans doute) ;
 * la façade ou (exclusif) le drapeau (mais on perd une des 2 infos) ;
 
 Pour les bâtiments locaux, départementaux, régionaux, j'avais un temps 
 envisagé de proposer de mettre les couleurs de l'entité (armoiries de la 
 ville, logo du département/de la région), mais là encore, je me disais que ça 
 serait peut-être compliqué à lire (les armoiries d'une ville sont-elles bien 
 connues, au moins de ses habitants ?) et ferait beaucoup d'icônes à ajouter...
 


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

Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)

[Vladimir Vyskocil]

On 11 mars 2013, at 21:45, Philippe Verdy verd...@wanadoo.fr wrote:

 As-tu un exemple concret quelque part où tu voies réellement la
 boursouflure que tu décris ? A mon avis si tu la vois c'est que les
 voies après la séparation n'ont pas seulement la différence
 oneway=yes mais ont changé de nature (bref un problème de données
 existantes mais pas un problème du rendu actuel).

Je parle de ce genre de choses : 
http://www.openstreetmap.org/browse/node/307405994
Ici par exemple l'emprise de la chaussée est a peu près équivalent avant et 
apres la séparation des deux voies mais le rendu exagère beaucoup la différence 
alors que si la largeur des voies à sens unique étaient divisisé par deux cela 
serait plus proche de la réalité

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

Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)

[Vladimir Vyskocil]

On 12 mars 2013, at 09:14, Christian Quest cqu...@openstreetmap.fr wrote:

 Le rendu ne fait que transcrire les données qui à mon avis exagèrent
 l'angle dans le cas que tu indiques... on a vraiment l'impression
 qu'il y a comme une chicane.

Le problème c'est que le point de jonction est sensé être a l'endroit physique 
ou les voies se séparent ou se raccordent, idem pour une sortie d'autoroute par 
exemple ou ce point devrait être juste a l'endroit après lequel il n'est plus 
possible de prendre la bretelle (cf quelque part dans le wiki) alors que si on 
tagguait pour le rendu (ouch c'est mal ;-) on mettrait ces points beaucoup plus 
éloignés pour avoir une transition plus douce.

 
 Je pense que le raccord entre traits épais et fins risque d'être
 délicat, mais rien n'est impossible, c'est juste un peu plus compliqué
 à traiter pour que ça soit graphiquement propre.

Oui c'est sur qu'une fois confronté a tous les cas possibles plus ou moins 
justes vis a vis de la réalité...

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

Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)

[Vladimir Vyskocil]

On 12 mars 2013, at 10:38, Christian Quest cqu...@openstreetmap.fr wrote:

 C'est un essai... un peu radical et pas très heureux.
 
 Il y a plein de problèmes:
 - les angles réels sont lissés (il ne faudrait lisser qu'en dessous
 d'une certaine flèche)
 - les textes ne sont pas positionnés sur les tracés lissés

Est-ce qu'il n'est pas possible de limiter l'action des courbes de bézier 
(bspline,... ou ce qui est utilisé ici) autour d'un angle pour modifier la 
route que très localement ce qui permettrait par exemple d'avoir des angle a 
90° qui le resterait globalement mais dont seulement l'angle serait raboté ?

 
 Ce lissage donne quand même de bons résultats sur les railway=rail et
 les highway=motorway ainsi que les junction=roundabout
 


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

Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)

[Vladimir Vyskocil]

On 12 mars 2013, at 13:15, Jo. perche...@gmail.com wrote:

 Pour le rendu, ça doit être très complexe mais il faudrait qu'à la jonction 
 les voies en sens unique soient légèrement décalé… mais je présume que tu a 
 déjà faire la même réflexion dans ton coin.

C'est pas si mal pour un premier essai et le décalage de la source des voies 
en sens unique comme dit plus haut pourrait bien aider mais cela doit surement 
être un peu complexe à traiter en SQL...
Ensuite il y a le probleme du rendu des transitions, des line cap qui se 
voient trop... peut etre qu'il est possible d'utiliser un bout carré et coller 
par dessus un trapèze en SVG ?

 
 
 Le 12 mars 2013 12:30, Christian Quest cqu...@openstreetmap.fr a écrit :
 Pour le rendu (propre) des lanes=*, c'est pas gagné !
 
 Comme je m'y attendais, les raccords sont très moches et ce n'est même
 pas lié à un éventuel décalage avec les oneway...
 
 Juste un essai:
 http://wiki.openstreetmap.org/w/images/1/1b/Test-highway-lanes.png
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr
 

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

Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)

[Vladimir Vyskocil]

Justement je viens de voir ce style pour JOSM : 
http://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes
qui vient de sortir et qui permet de visualiser dans l'éditeur tous les tags 
liés aux lanes, etc...
L'exemple donné est un peu étrange, notamment la voie Roma A1 qui part à 
angle droit vers le bas...

On 12 mars 2013, at 12:30, Christian Quest cqu...@openstreetmap.fr wrote:

 Pour le rendu (propre) des lanes=*, c'est pas gagné !
 
 Comme je m'y attendais, les raccords sont très moches et ce n'est même
 pas lié à un éventuel décalage avec les oneway...
 
 Juste un essai:
 http://wiki.openstreetmap.org/w/images/1/1b/Test-highway-lanes.png
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)

[Vladimir Vyskocil]

Récemment je me suis demandé pourquoi aucun rendu courant ne traite les voies 
en sens unique en les traçants deux fois moins larges par défauts que les voies 
en double sens car le rendu est souvent assez moche quand par exemple une route 
se sépare en 2 voies pour chaque sens sur une petite distance pour ensuite 
re-fusionner, ça fait des boursouflures pas belles et qui ne représentent pas 
la situation réelle. La largeur de la route pourrait aussi tenir compte de 
l'attribut lanes.
C'est sur que dans un premier temps certains endroits seraient rendu 
bizarrement si on a triché sur la position des voies mais cela permettrait de 
corriger.
C'est possible sur le super rendu FR ?

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

Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)

[Vladimir Vyskocil]

Le 11 mars 2013 à 17:12, Philippe Verdy verd...@wanadoo.fr a écrit :

 Le 11 mars 2013 16:23, Vladimir Vyskocil vladimir.vysko...@gmail.com a 
 écrit :
 Récemment je me suis demandé pourquoi aucun rendu courant ne traite les 
 voies en sens unique en les traçants deux fois moins larges par défauts que 
 les voies en double sens car le rendu est souvent assez moche quand par 
 exemple une route se sépare en 2 voies pour chaque sens sur une petite 
 distance pour ensuite re-fusionner, ça fait des boursouflures pas belles 
 et qui ne représentent pas la situation réelle. La largeur de la route 
 pourrait aussi tenir compte de l'attribut lanes.
 
 Les boursouflures dont tu parles ne sont pas plus épaisses que
 lécartement fait entre les voies. Mais si ta solution était adoptée,
 juste à l'endroit de la séparation la route aurait tout à coup un
 rétrécissement de moitié de sa largeur... ce qui serait encore pire !

Mais non pas du tout car chaque voie à sens unique devrait être axé sur le 
prolongement de la voie correspondante issue de la route à double sens et de 
largeur 1/2 (ou un poil moins). La transition entre les deux devrait être 
absorbée par l'arrondi au bout du segment en double sens. 

 
 

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

Re: [OSM-talk-fr] l'ile Saint-Laurent a coulé

[Vladimir Vyskocil]

Le problème vient peut être du fait qu'il y a des tags sur la relation 
(natural=water,...) et d'autres sur les membres de la relation en outer 
(waterway=riverbank,...), il faudrait choisir.

Vlad.

On 4 mars 2013, at 09:53, Samy Mezani samy.mez...@wanadoo.fr wrote:

 Bonjour,
 
 le 04/03/2013 09:32, claude marani a écrit:
 Bonjour
 
 Depuis quelques temps (je ne sais pas trop) l'Ile Saint-Laurent à Chalon
 sur Saône a coulé.
 http://osm.org/go/0A5qNeEOk--
 J'ai constaté le problème la semaine dernière sur d'autres iles de cette zone 
 et j'ai essayé de voir quel tag était en était la cause. Seul le natural=land 
 fait réapparaître les îles sur mapnik mais ce n'est pas satisfaisant.
 J'ai remplacé ce dernier à l'instant par place=islet mais disparition 
 totale...
 
 Toute solution m'intéresse également.
 
 Samy
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Bing Maps update

[Vladimir Vyskocil]

Cool, tout le littoral sud-est de la France est concerné, chez moi les images 
sont de novembre 2012. La résolution est assez moyenne mais très largement 
suffisante.

On 1 mars 2013, at 12:00, Eric Sibert courr...@eric.sibert.fr wrote:

 Et aussi :
 
 http://www.bing.com/community/site_blogs/b/maps/archive/2013/02/28/new-top-of-the-world-imagery.aspx
 
 Eric
 
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk] Display names of crossroads

[Vladimir Vyskocil]

 
 Where would you place this node if it is a more complex crossing?
 Like a crossing of 2 roads with dual carriage ways?


I just saw one such case in Tokyo yesterday :

http://www.openstreetmap.org/browse/node/254367454

Here the two nodes with traffic_signals tags carry the name (I suppose it's the 
name of this crossing but I don't read japanese...)


 you could draw a polygon around the crossing with junction=*, name=*
 and area=yes

Ok, seems right for me.

 
 cheers
 Martin
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk-fr] La corée du nord sur gmaps

[Vladimir Vyskocil]

J'ai posté un commentaire sur l'article des ecrans.fr (Libération) pour faire 
remarquer l'oublie d'OSM :

http://www.ecrans.fr/forums/viewtopic.php?pid=97245#p97245

La réponse d'un autre internaute me sidère... : 

Et Nokia Maps propose aussi la Corée du Nord depuis au moins 2 ans. Mais Nokia, 
c'est une boîte au trois quart morte, donc pas terrible. Quant à 
OpenStreetMaps, c'est libre donc c'est beaucoup trop compliqué pour 
l'utilisateur de base (en plus ça ne doit marcher que sous Linux, donc 
nécessité de recompiler son kernel pour activer l'option maps, etc). Bref 
heureusement que Google est là pour _vraiment_ faire avancer les choses.


Vlad.

On 31 janv. 2013, at 02:41, Severin MENARD severin.men...@gmail.com wrote:

 Et tous les médias suivent, Le Monde pompant allègrement les mêmes 
 andouilleries :
 http://www.lemonde.fr/technologies/article/2013/01/29/google-rend-la-coree-du-nord-plus-transparente_1823754_651865.html
 
 On devrait peut-être contacter le journaliste ?
 
 
 Severin
 
 
 --
 
 Message: 2
 Date: Wed, 30 Jan 2013 07:06:01 +0100
 From: Stéphane Henriod s...@henriod.info
 To: Discussions sur OSM en français  talk-fr@openstreetmap.org
 Subject: Re: [OSM-talk-fr] La corée du nord sur gmaps
 Message-ID:
 CAK6pVBWDYyZdP8pjPLgxkU2eAEZ503zjVtC=oq40lir42cv...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8
 
 OSM a encore beaucoup à faire pour se faire connaître du grand public et
 des média...
 
 Quand je lis sur CNN (
 http://edition.cnn.com/2013/01/29/tech/north-korea-google-maps/index.html):
 
 *Google said a community of citizen cartographers used the Internet
 search giant's Google Map Maker http://www.google.com/mapmaker software
 over a period of years to pinpoint road and place names. Google Map Maker
 works in a similar way to Wikipedia, allowing users to add, edit and review
 information.
 
 *Voilà maintenant que Google Map Maker est comparé à Wikipedia... c'est pas
 nous ça, normalement?
 
 @ Florian: une zone blanche sur Google:
 http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemaplon=71.56009lat=37.49346zoom=14
 
 --
 Le mot progrès n'aura aucun sens tant qu'il y aura des enfants malheureux
 -- Albert Einstein
 
 A journey does not need reasons. Before long, it proves to be reason
 enough in itself. One thinks that one is going to make a journey, yet soon
 it is the journey that makes or unmakes you. -- Nicolas Bouvier
 
 Photos de voyages, photos de montagne: http://www.henriod.info
 
 
 2013/1/29 Philippe Verdy verd...@wanadoo.fr
 
  Le 29 janvier 2013 15:09, Florian LAINEZ winner...@free.fr a écrit :
 
  Salut,
  Je vois que La Corée du Nord est maintenant mappée sur Gmaps :
  http://www.clubic.com/internet/univers-google/google-maps/actualite-538032-google-maps-cartographie-coree-nord.html
  Bon cela reste très parcellaire, et OSM n'a pas a rougir de la
  comparaison. En fait c'est très variable selon les zones.
 
  Dommage en tout cas, j'adorai zoomer sur cette partie du Monde pour
  présenter OSM à un débutant via http://tools.geofabrik.de/mc/ !
  Vous auriez d'autres zones blanches à me suggérer ?
 
 
  Pour la Corée du Nord, la zone de la capitale est plutôt mieux sur OSM que
  sur GMaps, mais si on va plus au Nord à la frontière de la Chine ou en
  Chine de l'autre côté de cette frontière... OSM peut encore progresser...
 
  En allant moins loin, on peut aussi voir notre retard pour le sud de la
  Tunisie. Il ne faudrait pas grand chose pour faire mieux que Google
  pourtant car il ne détaille pas tant de choses que ça.
  On note que Google semble plus avancé souvent uniquement parce qu'il a
  classé des routes plus importantes alors que dans OSM ce ne sont que des
  routes non classées qui n'apparaissent même pas sans qu'on zoome à un
  niveau assez haut pour les voir (ce sont pourtant des nationales). Et il
  y a sans doute un problème de classification du parc national tunisien.
 
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-fr
 
 
 -- section suivante --
 Une pièce jointe HTML a été nettoyée...
 URL: 
 http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130130/aff2a1a7/attachment-0001.html
 
 --
 
 Message: 3
 Date: Wed, 30 Jan 2013 07:52:58 +0100
 From: Etienne Trimaille etienne.trimai...@gmail.com
 To: Discussions sur OSM en français  talk-fr@openstreetmap.org
 Subject: Re: [OSM-talk-fr] La corée du nord sur gmaps
 Message-ID:
 CAMtDFLLxk=CNyeo3vZ84f4LemT=vCYg3ZYsaG2S4=dewber...@mail.gmail.com
 Content-Type: text/plain; charset=iso-8859-1
 
 Encore plus proche de nous :
 http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemaplon=18.35933lat=43.85352zoom=15
 
 
 Le 30 janvier 2013 07:06, Stéphane Henriod s...@henriod.info a écrit :
 
  OSM a encore beaucoup à faire pour se faire connaître du grand public et
  des média...
 
  Quand je lis sur 

Re: [OSM-talk-fr] Ou est le nom des oceans ?

[Vladimir Vyskocil]

Oui l'approche 2 me semble la bonne, d'ailleurs je pensais qu'il n'y avait que 
celle ci d'officielle et que ceux qui utilisent natural=wood le font presque 
toujours en méconnaissance de cause (en France métropolitaine). J'ai déjà eu a 
changer des natural=wood autour de chez moi en landuse=forest.
En ce qui concerne le rendu je pense que les deux tags devraient etre rendu de 
manière identiques ou presque.

Vlad.

On 31 janv. 2013, at 17:04, Jo. perche...@gmail.com wrote:

 Je ne pense pas que natural=wood décrive systématiquement une foret primaire 
 mais inversement, en cas de foret primaire c'est bien ce tag qu'il faut 
 utiliser.
 
 Suite à ton message, j'ai consulté le wiki et il y a 3 approches de décrite 
 sur http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood
 Approche 1 : en France casiement tout les ensemble boisé me semble géré ou 
 presque (j'en ai pas la confirmation). Dans cette approche, l'utilisation 
 associée de natural=wood serait systématique et landuse=forest ajouté quand 
 on connaît l'utilisation de la zone ;
 Approche 2 : en France, natural=wood serait rarement applicable (ancienne 
 foret primaire) et landuse=forest quasiment systématique (foret exploitée + 
 foret gérée) laissant place à natural=wood quand c'est possible ;
 Approche 3 : Il y a une distinction selon l'utilisation économique des 
 surfaces. En cas de sylviculture ce serait landuse=forest, autrement 
 natural=wood. Cela implique de connaître les utilisations locale, avec Bing 
 ce n'est pas possible ;
 Personnellement l'approche n°3 semble réellement complexe à appliquer et à 
 maintenir à jour. L'approche n°1 modifierai radicalement le rendu pour la 
 France en zoom 8 et 9 (même si on ne tag pas pour le rendu).
 
 Si il n'y aurai qu'une seule approche je recommanderai la n°2 (pour la 
 France) consistant à utiliser par défaut landuse=forest et d'identifier les 
 anciennes foret primaire de France (cela doit être gérable) pour les taguer 
 spécifiquement en natural=wood.
 L'utilisation de natural=wood serait envisageable également pour les forets 
 ancienne (qui ne sont pas tous le temps des foret primaire). Dans ce cas, 
 elles seraient identifiées suite à des recherches ou à des connaissances 
 locale, l'utilisation du tag name=* y serait souvent associé.
 
 
 Qu'en pense tu ? Le sujet m’intéresse car je commence à contribuer dans une 
 zone beaucoup plus boisée qu'où j'habite et cela me permettrait d'avoir une 
 idée précise pour garder une cohérence avec les autres régions de France.
 

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

Re: [OSM-talk-fr] Ou est le nom des oceans ?

[Vladimir Vyskocil]

On 30 janv. 2013, at 10:28, Jo. perche...@gmail.com wrote:

 J'en profite pour ajouter un autre problème de rendu minime.
 
 OSM affiche de belle étendue verte pour les forets (exploitée pour la 
 sylviculture) mais n'affiche pas les bois (forets non exploitée pour la 
 sylviculture). Au fil des années et des ajustement, ces étendue verte 
 diminueront car réellement ce sont principalement des foret non exploitée.

J'ai l'impression qu'en France natural=wood est souvent utilisé à tord la ou 
landuse=forest serait plus approprié, il ne doit plus rester beaucoup de forêt 
primaire.



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

Re: [OSM-talk-fr] Kort... un jeu pour corriger des erreurs OSM

[Vladimir Vyskocil]

On 29 janv. 2013, at 08:51, Francescu GAROBY windu...@gmail.com wrote:

 Ni sur Firefox (PC ou Mobile), alors que les 2 ont l'API de géolocalisation.

Il semble que Kort a besoin d'un navigateur basé sur webkit (Safari, Safari 
Mobile, Chrome,...), c'est bien dommage quand même...

 
 Francescu
 
 Le 29 janvier 2013 08:49, Vladimir Vyskocil vladimir.vysko...@gmail.com a 
 écrit :
 L'API de geolocalisation doit être disponible et fonctionnelle pour que 
 l'application démarre.
 
 
 
 Le 29 janv. 2013 à 07:14, pdora...@mac.com (Pierre-Alain Dorange) a écrit :
 
  Christian Quest cqu...@openstreetmap.fr wrote:
 
  Connaissez-vous Kort ?
 
  http://play.kort.ch/
 
  Ca ne fonctionne ni sur iMac,ni sur iPad...
 
  --
  Pierre-Alain Dorange
  OSM experiences : http://www.leretourdelautruche.com/map/
 
 
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-fr
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 -- 
 Cordialement,
 Francescu GAROBY
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Kort... un jeu pour corriger des erreurs OSM

[Vladimir Vyskocil]

 
 Il semble que Kort a besoin d'un navigateur basé sur webkit (Safari, Safari
 Mobile, Chrome,...), c'est bien dommage quand même...
 
 
 Bizarre tout de même que cette liste n'inclue pas l'iPhone (Webkit est
 pourtant à la base de Safari chez Apple) !

Si, Safari Mobile est le navigateur d'iOS.

 Kort ne sera donc
 disponible que sur les mobiles et tablettes Android ?

Donc aussi iPhone et iPad.

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


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

Re: [OSM-talk-fr] Kort... un jeu pour corriger des erreurs OSM

[Vladimir Vyskocil]

Opera sort un navigateur basé sur webkit sur iOS car ils n'ont pas d'autres 
choix car Apple impose l'utilisation du moteur web natif (donc basé sur webkit) 
pour tout navigateur alternatif.
Chrome pour iOS est également dans ce cas, il utilise le composant natif pas la 
version de webkit propre à Google (avec le moteur Javascript à eux)
Opera a également sorti un pseudo navigateur sur iOS il y a quelque temps en 
contournant le problème des restrictions imposés par Apple, le rendu des pages 
étaient fait par les serveur d'Opera, le navigateur sur iOS recevait 
directement le résultat (bien compressé).

On 29 janv. 2013, at 10:30, Philippe Verdy verd...@wanadoo.fr wrote:

 Pour info:
 
 http://www.clubic.com/navigateur-internet/actualite-536538-ice-navigateur-opera-software-webkit.html
 
 Bref c'est bientôt fini Opera utilisant la version mini du moteur
 Presto sur Android et sur iPhone (Opera n'arrive plus à le faire tenir
 sur les mobiles pour supporter HTML5 et « rester dans la course »). Ce
 ne sera plus Opera Mini mais Opera Ice.
 
 Presto en revanche reste supporté pour les PC et Opera Embedded. Et
 Opera conserve son moteur Javascript (et il ne passe pas en au moteur
 V8 de Google sur les appareils Android, ni au moteur Javascript de
 Safari sur les iPhones).
 
 Le 29 janvier 2013 10:21, Philippe Verdy verd...@wanadoo.fr a écrit :
 Le 29 janvier 2013 09:52, Vladimir Vyskocil
 vladimir.vysko...@gmail.com a écrit :
 
 On 29 janv. 2013, at 08:51, Francescu GAROBY windu...@gmail.com wrote:
 
 Ni sur Firefox (PC ou Mobile), alors que les 2 ont l'API de géolocalisation.
 
 
 Il semble que Kort a besoin d'un navigateur basé sur webkit (Safari, Safari
 Mobile, Chrome,...), c'est bien dommage quand même...
 
 Cela inclut maintenant aussi Opera, qui abandonne le développement son
 propre moteur pour utiliser depuis peu Webkit (je n'ai pas vérifié si
 cela concerne toutes les versions d'Opera, il va rester bon nombre de
 versions Embedded d'Opera, dans les téléviseurs par exemple, à moins
 que bientôt eux aussi adoptent Webkit dans la version tunée par
 Opera).
 
 Bizarre tout de même que cette liste n'inclue pas l'iPhone (Webkit est
 pourtant à la base de Safari chez Apple) ! Kort ne sera donc
 disponible que sur les mobiles et tablettes Android ?
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Kort... un jeu pour corriger des erreurs OSM

[Vladimir Vyskocil]

Le 29 janv. 2013 à 11:53, Xavier x.larc...@laposte.net a écrit :

 À vérifier, mais il me semble que la limitation de vitesse sur rond-point est 
 de 30km/h. Je m'étais déjà posé la question et c'est un agent des forces de 
 l'ordre qui m'avait répondu cela.
 C'est pour ça que je dit que c'est à vérifier ;-)

C'est bien possible mais cela ne change pas le fait qu'il serait absurde 
d'ajouter maxspeed=30 sur tous les rond-points de France !


 Comme une limite de vitesse spécifique prend fin au carrefour suivant (art 
 13 de la Convention de Vienne - art 63 de l'instruction 
 interministerielle sur la signalisation routière), en instituer une dans un 
 rond-point est une démarche assez folklorique nécessitant un panneau de 
 rappel après chaque embranchement, ce qui n'est jamais fait. On peut donc 
 considérer que dans un rond point s'applique la limite générale de vitesse 
 applicable à la voirie en question, donc à priori 90 hors agglomération et 
 50 en agglomération. 
 
 Exception au principe: il n'est pas besoin de rappeler la limite spéciale de 
 vitesse lorsqu'on est dans une zone XX, à ce moment là dans le rond-point 
 c'est cette limitation de zone qui s'applique.
 
 Une autre limite est posée par les lois de la physique, dont la force 
 centrifuge, combinée à l'obligation que fait le code d'adapter sa vitesse 
 aux circonstances, mais ceci est une autre histoire. ;)
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Kort... un jeu pour corriger des erreurs OSM

[Vladimir Vyskocil]

Trop fort, j'ai hâte de quitter le bureau pour l'essayer en vrai, je vois que 
j'ai 549 places a rattraper dans le classement ! ;-)
Une petite suggestion d'amélioration, est-ce qu'il serait possible de détecter 
le lancement du site en tant que webapp sur iOS et passer l'affichage en 
plein-écran pour donner encore plus l'illusion d'une application native ?

Vlad.
 
On 28 janv. 2013, at 09:56, Christian Quest cqu...@openstreetmap.fr wrote:

 Ca y est, Kort (http://play.kort.ch/) est traduit en français :)
 
 Il y a eu pas mal de petites améliorations ici ou là.
 Je rappelle que Kort est destiné à fonctionner sur un smartphone ou une 
 tablette sur le terrain, pas en chair-mapping ;)
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Kort... un jeu pour corriger des erreurs OSM

[Vladimir Vyskocil]

Un type de question qui revient souvent est la limitation de vitesse dans un 
rond-point... il me semble n'y avoir jamais vu de panneau de limitation de 
vitesse ?
Il y a souvent un panneau quand on sort du rond-point par contre.

Vlad.

On 28 janv. 2013, at 09:56, Christian Quest cqu...@openstreetmap.fr wrote:

 Ca y est, Kort (http://play.kort.ch/) est traduit en français :)
 
 Il y a eu pas mal de petites améliorations ici ou là.
 Je rappelle que Kort est destiné à fonctionner sur un smartphone ou une 
 tablette sur le terrain, pas en chair-mapping ;)

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

Re: [OSM-talk-fr] Kort... un jeu pour corriger des erreurs OSM

[Vladimir Vyskocil]

L'API de geolocalisation doit être disponible et fonctionnelle pour que 
l'application démarre. 



Le 29 janv. 2013 à 07:14, pdora...@mac.com (Pierre-Alain Dorange) a écrit :

 Christian Quest cqu...@openstreetmap.fr wrote:
 
 Connaissez-vous Kort ?
 
 http://play.kort.ch/
 
 Ca ne fonctionne ni sur iMac,ni sur iPad...
 
 -- 
 Pierre-Alain Dorange
 OSM experiences : http://www.leretourdelautruche.com/map/
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] Une analyse intéressante sur le nombre de nodes par way

[Vladimir Vyskocil]

J'ai lu ce billet que j'ai trouvé intéressant :

http://ksmapper.blogspot.fr/2013/01/too-much-of-good-thing.html

Il y a tout une partie ou l'import du bâti du cadastre français est pointé du 
doigts avec des arguments qui se tiennent mais la critique est assez modéré et 
il n'est pas le seul critiqué, Tiger, Canvec,... sont aussi pointés.
Je poste ceci car il me semble que cela rejoint la discussion qui a été initiée 
sur un post-processing des données du bati pour notamment détecter les découpes 
artificielles des batiments que l'on pourrait fusionner. 
Est-ce qu'il ne pourrait pas aussi y avoir une analyse (Osmose ?) sur le nombre 
de nodes au mètre sur les batiments pour détecter ce que l'on voit assez 
souvent : des courbes avec une infinité de noeuds inutiles voir nuisibles car 
souvent le contour est tout crénelé.

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

Re: [OSM-talk-fr] Une analyse intéressante sur le nombre de nodes par way

[Vladimir Vyskocil]

On 23 janv. 2013, at 11:50, Pieren pier...@gmail.com wrote:

 2013/1/23 Vladimir Vyskocil vladimir.vysko...@gmail.com:
 
 Je poste ceci car il me semble que cela rejoint la discussion qui a été
 initiée sur un post-processing des données du bati pour notamment détecter
 les découpes artificielles des batiments que l'on pourrait fusionner.
 
 Initiée par moi ;-)
 
 Le billet est intéressant mais il y a une erreur dans l'analyse. Le
 nombre de nodes/mètre n'est pas forcément une information pertinente
 pour l'import cadastre. Si on exclue le problème des découpages
 artificiels finalement assez mineur, notre import du bâti ne fournit
 pas trop de noeuds. Il y a surtout un problème de modélisation de bâti
 où nous tagguons chaque polygone comme un bâtiment alors qu'en
 réalité, c'est souvent une pièce ou une terrasse ou une cheminée ou un
 groupe de pièces ou un étage. Un découpage souvent subjectif mais
 surtout une modélisation dans OSM complètement fausse. On devrait
 pouvoir en conserver une bonne partie s'ils étaient correctement
 taggués (et vérifiés ce qui est très difficile sans se rendre sur
 place ou même à l'intérieur). Seul le contour extérieur doit porter le
 tag building=yes. Les pièces, les cheminés ou les étages sont à
 modéliser avec d'autres tags que j'ai déjà mentionné dans le fil de
 discussion précédent.

Je suis d'accord sur ce point mais il y a malgré tout aussi un problème sur le 
nombre de noeuds pour certains batiments et on ne peut pas dire que c'est pour 
rendre le tracé plus précis car on dirait plus un probleme lors de la saisie du 
cadastre vectoriel (numérisation, ocr ?) qui rend le tracé irrégulier et 
surchargé de points.
Comme par exemple ici :

http://www.openstreetmap.org/browse/way/13738

Oui c'est moi qui ai importé ceci, j'avais un peu nettoyé quand je remarquais 
ce genre de chose mais beaucoup on du passer au travers...


 
 Notre problème principal n'est donc pas le nombre trop important de
 noeuds, mais le nombre trop important de ways marqués building=yes
 qui n'en sont pas.
 
 Pieren
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk] How to map mountain pass in Poltach 2

[Vladimir Vyskocil]

And this IMHO important feature to have on a map is still not rendered in 
Mapnik on the main OSM site... I always saw the request to have it added in the 
default style since I joined OSM (more than 3 years ago). I think this has 
something to do with the default pgsql import style not having the following 
key or keys : 

 
 is there a particular reason to use a new key for this, instead of
 e.g. natural=mountain_pass (or natural=pass)? There is only few of
 these I admit: http://taginfo.openstreetmap.org/search?q=natural%3Dpass
 

There was also a problem to have the symbol oriented right with the old Mapnik 
version, but now it should be possible, is it ?

Regards,
Vlad.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Suivi des limites communales ( était Nouvel outil pour repérer les contributeurs ...)

[Vladimir Vyskocil]

J'ai récemment fini les communes du Var (83) en raster mais une commune : 
GAREOULT (ref:INSEE 83064) est toujours listée dans 
http://suivi.openstreetmap.fr/communes/communes.csv.txt alors qu'elle semble ok 
dans JOSM et par 
http://osmose.openstreetmap.fr/map/?zoom=13lat=43.33949lon=6.04459layers=BFFTFFFTitem=6010,6020,6030,6040,6050,6060level=1,2,3
Savez pourquoi, car je ne vois pas.

Vlad.


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

Re: [OSM-talk-fr] Suivi des limites communales ( était Nouvel outil pour repérer les contributeurs ...)

[Vladimir Vyskocil]

On 15 janv. 2013, at 12:26, Vincent de Chateau-Thierry v...@laposte.net wrote:

 Bonjour,
 
 De : Vladimir Vyskocil 
 
 J'ai récemment fini les communes du Var (83) en raster 
 
 \o/

Content que cela fasse plaisir :)
Mais il y a encore du boulot car j'ai vu qu'une partie des communes provient de 
GeoFLA dont la précision est vraiment faible. J'ai mis à jour certaines des 
limites provenant de GeoFLA quand elles étaient communes (!) avec les dernières 
que j'ai entré depuis le cadastre raster (la aussi la précision et la 
concordance entre 2 communes voisines laisse parfois à désirer), et j'ai du 
oublier d'enlever pas mal de tag source=GeoFLA dans l'opération...

 
 On devrait pouvoir définir tous les arrondissements du 83 alors :-)
 http://layers.openstreetmap.fr/?zoom=9lat=43.56019lon=6.22958layers=0B000FFTTF

Je passe mon tour !

 
 mais une commune : GAREOULT (ref:INSEE 83064) est toujours listée dans 
 http://suivi.openstreetmap.fr/communes/communes.csv.txt alors qu'elle semble 
 ok dans JOSM
 
 
 Il y a un croisement malvenu sur ce point :
 http://www.openstreetmap.org/browse/node/2102071892
 
 (merci à http://analyser.openstreetmap.fr/cgi-bin/index.py )

Merci, je n'ai pas pensé à vérifier avec cet outils. C'est corrigé !

 
 vincent


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

Re: [OSM-talk-fr] Suivi des limites communales ( était Nouvel outil pour repérer les contributeurs ...)

[Vladimir Vyskocil]

On 15 janv. 2013, at 14:27, Christian Quest cqu...@openstreetmap.fr wrote:

 Le 15 janvier 2013 14:19, Vladimir Vyskocil vladimir.vysko...@gmail.com a 
 écrit :
 Content que cela fasse plaisir :)
 Mais il y a encore du boulot car j'ai vu qu'une partie des communes provient 
 de GeoFLA dont la précision est vraiment faible. J'ai mis à jour certaines 
 des limites provenant de GeoFLA quand elles étaient communes (!) avec les 
 dernières que j'ai entré depuis le cadastre raster (la aussi la précision et 
 la concordance entre 2 communes voisines laisse parfois à désirer), et j'ai 
 du oublier d'enlever pas mal de tag source=GeoFLA dans l'opération...
 
 
 
 Tu as des exemples ? 

http://www.openstreetmap.org/browse/relation/2162212 par exemple et d'autres 
dans les alentours

 
 Vu la piètre précision de GEOFLA, on avait décidé ici même de ne pas faire 
 d'import en dehors des nœuds place manquants.

Je vais progressivement les remplacer en utilisant l'infrastructure en place, 
donc merci de ne pas tout effacer ;-)

 
 On approche les 87% de communes... \o/ +1
 
 -- 
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Suivi des limites communales ( était Nouvel outil pour repérer les contributeurs ...)

[Vladimir Vyskocil]

On 15 janv. 2013, at 15:46, Pieren pier...@gmail.com wrote:

 2013/1/15 Vladimir Vyskocil vladimir.vysko...@gmail.com:
 http://www.openstreetmap.org/browse/relation/2162212 par exemple et d'autres
 dans les alentours
 
 Ce way:
 http://www.openstreetmap.org/browse/way/161413830
 
 est marqué source=GeoFLA alors que sa résolution semble provenir du 
 cadastre...

Oui j'ai vu ça... je pensais que quand le plugin cadastre demande pour ajouter 
son tag lors de l'upload il le faisait partout mais en fait non, soit parce que 
la source était déjà renseignée soit parce que way n'a été que modifié.
Je vais revoir tout ça et remplacer la source=GeoFLA par cadastre- la ou 
j'ai utilisé le cadastre raffiner ce qui existait déjà.

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


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

Re: [OSM-talk-fr] Ils sont passés où les bâtiments???

[Vladimir Vyskocil]

On 20 déc. 2012, at 14:34, Ab_fab gamma@gmail.com wrote:

 Pour les plus téméraires, le script utilisé par Geofabrik pour la génération 
 est disponible dans le svn openstreetmap
 https://trac.openstreetmap.org/browser/subversion/applications/utils/export/osm2shp

On peut remettre les batiments et faire un commit l'air de rien ? ;-)
Plus sérieusement c'est embêtant cette histoire car j'utilise aussi 
régulièrement ces exports pour une appli iOS que j'ai developpé et le rendu 
avec les batiments est très utile (bien que beaucoup plus lourd).
Une question aussi, que se passe t'il quand les batiments enlevés sont le 
support a des POI, écoles, églises, adresses,... ils sont remplacés par un 
noeud portant les infos ?

Vlad.



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

Re: [OSM-talk-fr] Ils sont passés où les bâtiments???

[Vladimir Vyskocil]

Comme me l'a fait gentiment remarquer Ab_Fab, il ne s'agit que des fichiers SHP 
qui sont générés à partir des extracts OSM/PBF qui n'ont plus les batiments, 
ces derniers ne sont pas filtrés.

Vlad.

On 20 déc. 2012, at 15:29, partir-en-vtt ad...@partir-en-vtt.com wrote:

 Effectivement, qu'est-ce qui nous empêche de créer le service ? 
 
 Y'a pas un petit dédié qui traine pour faire ça ?
 
 
 
 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/Ils-sont-passes-ou-les-batiments-tp5741107p5741194.html
 Sent from the France mailing list archive at Nabble.com.
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Vladimir Vyskocil]

On 28 nov. 2012, at 19:20, Pieren pier...@gmail.com wrote:
  Si on veut distinguer deux entités, on peut aussi bien
 mettre des espaces avant et après le tiret pour lever toute ambiguité
 (Maisons-Alfort - Stade est assez clair).

Ce compromis me semble tout à fait acceptable car il résout à la fois le 
problème sémantique et l'utilisation de caractères typographique ésotériques 
pour 99.5% des contributeurs.

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

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Vladimir Vyskocil]

On 29 nov. 2012, at 09:56, JB jb...@mailoo.org wrote:

 Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire « 
 Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou « 
 Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre « 
 Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre « 
 Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ».
 
 Et je ne vois pas le problème à avoir une typo première version avec les 
 caractères les plus accessibles à tous (-) et un maniaque derrière qui 
 remettra une couche avec le beau tiret cadratin.
 
 On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux 
 moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette 
 règle quand on passe à la typographie.
 
Justement parce que la typographie c'est du rendu. On peut supposer qu'un 
moteur de rendu intelligent pourrait avoir des règles pour afficher un — 
lorsqu'il rencontre un  - .
 JB
 

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

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Vladimir Vyskocil]

On 29 nov. 2012, at 09:47, Philippe Verdy verd...@wanadoo.fr wrote:

 Pas pour Paris - Bruxelles - Brussels... Le tiret n'a pas le même sens, il 
 n'y a pas 3 entités mais 2 :
 Est-ce 'Paris - Bruxelles et Brussels, ou bien Paris et Bruxelles - 
 Brussels.
 
 Faut-il alors écrire Bruxelles / Brussels pour avoir Paris - Bruxelles / 
 Brussels et est-ce moins ambigu ?

Oui cela pourrait être une bonne façon d'entrer les données dans la base, le 
/ serait alors un séparateur de liste et  -  représenterait l'union.
Ensuite libre au moteur de rendu d'afficher ça de la bonne manière. 

 Faut-il alors écrire (et alors traduire...) De Paris à Bruxelles - 
 Brussels, à traduire ensuite dans toutes les langues ?
 

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

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Vladimir Vyskocil]

On 29 nov. 2012, at 11:15, Mikaël Cordon mikael.cor...@gmail.com wrote:

 Oui cela pourrait être une bonne façon d'entrer les données dans la base, le 
 / serait alors un séparateur de liste et  -  représenterait l'union.
 Ensuite libre au moteur de rendu d'afficher ça de la bonne manière.
 
 Attention, le caractère « / » a sa propre signification. Et pour les 
 cartographieurs qui reproduisent scrupuleusement les panneaux, « / » a pour 
 signification dans des version abrégées de « sur ». Exemple : « Argenton / 
 Creuse » ou « Argenton s/ Creuse », signifiant « Argenton sur Creuse » ; qui 
 deviendrait alors « Argenton — Creuse » ayant une toute autre signification.

Ok, une autre convention pourrait être trouvée mais l'exemple cité n'est pas 
bon car il ne faudrait pas entrer de versions abrégées des noms dans la base 
car la aussi c'est au moteur de rendu ou de recherche dans les données de faire 
les abréviations à la volée si besoin (autre débat, assez chaud chez les 
américains par exemple...)

 
 Cordialement,
 --
 Mikaël Cordon, mickey86

cordialement,
Vladimir.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Vladimir Vyskocil]

On 29 nov. 2012, at 12:45, Philippe Verdy verd...@wanadoo.fr wrote:

 Ce qui se complique encore quand les toponymes ***officiels*** espagnols 
 utilisent le / pour séparer les noms ***co-officiels*** issus de plusieurs 
 langues, ces deux langues ***devant*** toujours être citées ensembles et dans 
 l'ordre indiqué sans qu'on puisse en supprimer un ! C'est alors le même 
 toponyme dans les langues d'origine, les différences linguistiques étant 
 alors abolies dans la dénomination officielle pour la même entité (regardez 
 le Pays Basque espagnol par exemple).
 
 Dans ce cas le / ne signifie pas non plus sur, ***même*** en Français. 
 Comment alors faire un traitement automatique de substitution pour faire 
 joli ?
 
 Oui effectivement le / a sa propre sémantique dans ce cas, mais on ne doit 
 PAS l'utiliser comme s'il s'agissait d'une abréviation, même en français.
 
 Bref en aucun cas Argenton / Creuse ne signifie la même chose que 
 Argenton-sur-Creuse (ne pas oublier non plus les traits d'union ici !)
 
 Car en Espagne et même en français, ce / est un séparateur, distingué de 
 l'autre séparateur trait d'union qui est aussi utilisé pour juxtaposer deux 
 termes mais avec une autre signification.
 
 L'idée qu'un moteur de rendu peut librement remplacer la ponctuation est 
 totalement erronée, chacune a sa signification propre mais on ne peut pas la 
 déduire de la seule façon dont cette ponctuation est codée puisque pour cela 
 il faudrait coder ***aussi*** la sémantique.
 

Dans ce cas c'est le schema qui n'est pas bon et on aurait du partir par 
exemple sur un tag name multi-valué alors que l'on est clairement parti sur une 
solution simpliste qui revient a tagguer pour le rendu : on veut que les 2 noms 
s'affichent côte à côte séparés par un caractère lambda sans rien a avoir a 
changer aux moteurs de rendu actuels... 
Il faut également prendre en compte tous les outils de recherche qui vont faire 
comment pour se dépatouiller avec des données formatés avec des demi-espaces 
insécables ou je ne sais quelle curiosité de la langue française ?

Vladimir


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

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Vladimir Vyskocil]

On 29 nov. 2012, at 15:30, JB jb...@mailoo.org wrote:

 Le 29.11.2012 15:13, Vladimir Vyskocil a écrit :
 Il faut également prendre en compte tous les outils de recherche qui vont 
 faire comment pour se dépatouiller avec des données formatés avec des 
 demi-espaces insécables ou je ne sais quelle curiosité de la langue 
 française ?
 Euh, si un moteur sait trouver un « é » à partir d'un e, un « î » ou un « ï » 
 à partir d'un i, pourquoi ne trouverait-il pas un espace insécable, une fine 
 ou une autre curiosité à partir d'un espace ? Ou un tiret demi ou cadratin 
 entier à partir d'un trait d'union ? D'ailleurs, prennent-ils seulement en 
 compte ces caractères autres que les lettres dans leurs recherches ?
 
Dans ce cas que l'on ne parle pas de sémantique attachée à ces caractères si 
l'on ne doit pas en tenir compte...
Et il faut garder les pieds sur terre et ne pas trop espérer que d'ici peu les 
outils, les langages de programmation, les libs sachent gérer le fait qu'un 
caractère comme l'espace insécable ou le demi-espace doivent dans certains cas 
etre traités comme un simple espace, dans d'autre non, que les différents tirés 
matchent le -,... surtout quand ces outils sont développés 
internationalement et que toutes ces subtilités de la langue française ne vont 
parler en aucune façon à un développeur suédois (bien qu'il sera surement 
sensibilisé aux accents).

Vladimir 

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

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

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Vladimir Vyskocil]

Envoyé de mon iPad

Le 29 nov. 2012 à 16:57, Philippe Verdy verd...@wanadoo.fr a écrit :

 Non on ne veut pas 2 noms séparés, c'est un seul et même nom contenant deux 
 éléments.

Oui c'est ce que j'ai dit un nom multi-valué que le moteur de rendu pourra 
très bien afficher nom1 – nom2 par exemple.

 
 Et les moteurs de recherche n'ont strictement aucun problème avec ces 
 caractères qui ne sont pas des curiosités françaises mais présents par 
 défaut dans de nombreux protocoles, supportés par des encodages essentiels 
 (dont windows-1252 qui est le seul encodage par défaut d'HTML5, et UTF-8 qui 
 est le seul encodage par défaut d'XML et XHTML), présents dans toutes les 
 polices latines non restreintes à l'ASCII (et un très grand nombre de polices 
 d'autres écritures).

C'est surtout ceux qui cherchent qui peuvent avoir des soucis s'ils doivent 
utiliser le bon tiret ou le bon espace. 

 
 Ils ont d'autant moins de problème que les moteurs de recherche ont des 
 standards pour ça, je le répète: UCA et une norme ISO équivalente. Ils ont 
 été dans toutes les versions de CLDR, et même indiqués comme partie prenante 
 des ponctuations essentielles non seulement au français mais aussi à 
 l'anglais (même si les anciens claviers ne peuvent pas toujours les saisir, 
 il a toujours existé d'autres moyens que la saisie directe au clavier, même 
 pour ceux qui travaillent les fichiers XML pour OSM dans un éditeur de texte 
 basique, avec des entités de caractères mdash; ou entités numériques 
 Unicode).

Oui sûrement, mais on parle de gens qui ne savent même pas que ceci existe.

 
 Il y a même moins de complication à les utiliser que les caractères accentués 
 français pour les recherches ou le tri (là encore lire ce qu'en dit le 
 standard de collation UCA, ou la norme ISO équivalente ou la norme 
 française NF). Même avec une collation la plus basique (à un seul niveau, 
 c'est plus simple que les lettres accentuées françaises), la complication est 
 en faitdu même ordre quand on se reporte uniquement à la ponctuation ASCII.
 
 
 
 
 Le 29 novembre 2012 15:13, Vladimir Vyskocil vladimir.vysko...@gmail.com a 
 écrit :
 
 On 29 nov. 2012, at 12:45, Philippe Verdy verd...@wanadoo.fr wrote:
 
  Ce qui se complique encore quand les toponymes ***officiels*** espagnols 
  utilisent le / pour séparer les noms ***co-officiels*** issus de 
  plusieurs langues, ces deux langues ***devant*** toujours être citées 
  ensembles et dans l'ordre indiqué sans qu'on puisse en supprimer un ! 
  C'est alors le même toponyme dans les langues d'origine, les différences 
  linguistiques étant alors abolies dans la dénomination officielle pour la 
  même entité (regardez le Pays Basque espagnol par exemple).
 
  Dans ce cas le / ne signifie pas non plus sur, ***même*** en Français. 
  Comment alors faire un traitement automatique de substitution pour faire 
  joli ?
 
  Oui effectivement le / a sa propre sémantique dans ce cas, mais on ne 
  doit PAS l'utiliser comme s'il s'agissait d'une abréviation, même en 
  français.
 
  Bref en aucun cas Argenton / Creuse ne signifie la même chose que 
  Argenton-sur-Creuse (ne pas oublier non plus les traits d'union ici !)
 
  Car en Espagne et même en français, ce / est un séparateur, distingué de 
  l'autre séparateur trait d'union qui est aussi utilisé pour juxtaposer 
  deux termes mais avec une autre signification.
 
  L'idée qu'un moteur de rendu peut librement remplacer la ponctuation est 
  totalement erronée, chacune a sa signification propre mais on ne peut pas 
  la déduire de la seule façon dont cette ponctuation est codée puisque pour 
  cela il faudrait coder ***aussi*** la sémantique.
 
 
 Dans ce cas c'est le schema qui n'est pas bon et on aurait du partir par 
 exemple sur un tag name multi-valué alors que l'on est clairement parti sur 
 une solution simpliste qui revient a tagguer pour le rendu : on veut que les 
 2 noms s'affichent côte à côte séparés par un caractère lambda sans rien a 
 avoir a changer aux moteurs de rendu actuels...
 Il faut également prendre en compte tous les outils de recherche qui vont 
 faire comment pour se dépatouiller avec des données formatés avec des 
 demi-espaces insécables ou je ne sais quelle curiosité de la langue 
 française ?
 
 Vladimir
 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Dégats sur Coastline

[Vladimir Vyskocil]

Le rendu des côtes peut rester en l'état même après la régénération du fichier 
avec les données corrigés en tout cas tant que la tuile n'est pas à nouveau 
marquée dirty soit parce que son contenu (hors coastline) à changé soit parce 
qu'elle a été marquée explicitement /dirty. Il m'arrive parfois de retourner 
sur un endroit de la carte ou j'ai fait des corrections (quelques semaines voir 
mois avant le temps qu'elles soient bien prises en compte) sur la coastline et 
de régénérer les tuiles avec les url correspondantes augmentées de /dirty et 
après un refresh du cache du navigateur on voit enfin le nouveau tracé !

Vlad.

On 19 nov. 2012, at 00:28, Philippe Verdy verd...@wanadoo.fr wrote:

 Effectivement les côtes ont été réparées et reconnectées il y a maintenant 
 plus d'une semaine. Les tuiles ont dépuis été régénérées, mais sans remise à 
 jour du fichier des coastlines (si c'est le fichier mondial qui est utilisé, 
 le petit bout de Bretagne fermé arbitrairement par un trait vertical, voire 
 pas fermé du tout sur une grande longueur n'est visiblement pas la priorité 
 de ceux qui maintiennent le serveur Mapnik d'OSM).
 
 On peut se demander quand même pourquoi un tel fichier coastline n'a pas été 
 contrôlé avant pour vérifier qu'il se fermait bien avant de le sélectionner 
 pour une version suivante : au moins les anomalies auraient pu être corrigées 
 en mettant au minimum un trait dans la petite section manquante au lieu de 
 virer tout ce long segment (bien plus long que l'anomalie qui était là.
 
 Moralité : quand on a une anomalie de ligne de côte brisée, la réparation est 
 urgente avant qu'un fichier de coastline soit généré dans cet état car il va 
 être utilisé longtemps par le rendu Mapnik d'OSM.
 
 D'une façon générale quand une ligne de côte est affinée même sans erreur, la 
 mer va souvent ne pas suivre la nouvelle ligne de côte pendant assez 
 longtemps sur le rendu : on le voit régulièrement quand il y a de nouvelles 
 petites îles ajoutées (qui se retrouvent submergées), ou quand un estuaire 
 est mieux dessiné (on trouve des quais ou des routes dans l'eau, et des 
 plages qui ne bordent pas l'eau (j'ai déjà vu cela durer près de 2 mois...).
 
 Je me demande bien pourquoi Mapnik a encore besoin d'un fichier statique pour 
 la mer, étant donné la contrainte de direction qui est déjà imposée et permet 
 de savoir de quel côté est l'eau.
 
 
 Le 18 novembre 2012 11:32, Lapinos03 lapino...@free.fr a écrit :
 Pour en revenir à cette pseudo-catastrophe que je viens de découvrir avec 
 effroi, quelle est la périodicité des coastline regénérées ? Le lien 
 http://tile.openstreetmap.org ne propose pas d'indexage des fichiers contenus 
 dans son répertoire. Du coup, on ne sait même pas de quand date la dernière 
 génération. À moins qu'il existe un autre lien ?
 
 @+
 
 
 Le 12/11/12 11:29, Christian Quest a écrit :
 Signalé aussi ici: 
 https://help.openstreetmap.org/questions/17644/fr-rade-de-brest-assechee
 
 J'ai mis un mot sur IRC #osm... le problème c'est que la ligne de côte 
 utilisée par le rendu Mapnik n'est pas mise à jour à chaque rendu et qu'on 
 n'a pas de contrôle direct là dessus comme avec les données OSM.
 
 -- 
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Noms de magasins supprimés

[Vladimir Vyskocil]

On 17 nov. 2012, at 19:40, Christian Quest cqu...@openstreetmap.fr wrote:

 Pour info j'ai ouvert un ticket à ce sujet pour le groupe GA: 
 http://trac.openstreetmap.fr/ticket/137 

Ah merci, j'espère que ce contributeur comprendra que le but premier du projet 
n'est pas d'arranger les données pour faire joli sur la carte par défaut ;-)

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

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

Re: [OSM-talk-fr] Cartographie Fleuve Maroni Oyapoque Guyane

[Vladimir Vyskocil]

J'ai jeté un coup d'oeil sur cette zone par simple curiosité et le travail sur 
les innombrables bras de ces fleuves et toutes ces iles me parait colossal, 
bravo ! J'ai tout de même une remarque, il m'a semblé que par endroit le 
waterway=river (le linéaire) etait beaucoup plus grossièrement défini que les 
riverbank et qu'il apparait a des endroits non couvert par un riverbank alors 
qu'il pourrait être placé dans l'axe du bras principal du fleuve.

Vlad.

On 16 nov. 2012, at 12:07, Colin Durand colindur...@hotmail.com wrote:

 Le long du Maroni ou de l'Oyapock je ne suis pas sur que nous fassions 
 beaucoup d'erreur en qualifiant tous les sites d'illégaux :-( mais ce n'est 
 peut être pas à nous de le faire...Dans le doute je pensais les qualifier en 
 carrière en dessinant un polygone autour de leur extension. Moi en gros, 
 utilisateur coldurand, je remonte le fleuve et suis vers Grand Santi. Pareil 
 si tu vois de grosses erreurs n'hésites pas à me le signaler, je ne suis pas 
 un expert d'open street map.
 
 Pour les villages, tous pourraient être repérés à partir des orthos bing. 
 ensuite il faudrait que je me rapproche de mon ancien employeur en Guyane 
 pour avoir une autorisation d'utiliser les données. Toi du coup, pour 
 t'intéresser à ce coin tu connais la Guyane ?
 
 a +
 
 Colin
 
 
 
  From: talk-fr-requ...@openstreetmap.org
  Subject: Lot Talk-fr, Vol 76, Parution 110
  To: talk-fr@openstreetmap.org
  Date: Thu, 15 Nov 2012 20:19:36 +
  
  Envoyez vos messages pour la liste Talk-fr à
  talk-fr@openstreetmap.org
  
  Pour vous (dés)abonner par le web, consultez
  http://lists.openstreetmap.org/listinfo/talk-fr
  
  ou, par email, envoyez un message avec 'help' dans le corps ou dans le
  sujet à
  talk-fr-requ...@openstreetmap.org
  
  Vous pouvez contacter l'administrateur de la liste à l'adresse
  talk-fr-ow...@openstreetmap.org
  
  Si vous répondez, n'oubliez pas de changer l'objet du message afin
  qu'il soit plus spécifique que Re: Contenu du digest de Talk-fr...
  
  
  Thèmes du jour :
  
  1. Re: Cartographie Fleuve Maroni Oyapoque Guyane (Stéphane MARTIN)
  2. Re: Quelles fonctionnalités techniques vous manquent ? Mode
  d'édition polygone (Philippe Verdy)
  3. Re: Quelles fonctionnalités techniques vous manquent ? Mode
  d'édition polygone (Balaitous)
  4. Re: Landuse Multipolygon et rendu Mapnik (Jérome Armau)
  5. Re: Quelles fonctionnalités techniques vous manquent ? Mode
  d'édition polygone (Philippe Verdy)
  
  
  --
  
  Message: 1
  Date: Thu, 15 Nov 2012 14:46:15 -0300
  From: Stéphane MARTIN st3ph.mar...@laposte.net
  To: talk-fr@openstreetmap.org
  Subject: Re: [OSM-talk-fr] Cartographie Fleuve Maroni Oyapoque Guyane
  Message-ID: 50a52a67.3060...@laposte.net
  Content-Type: text/plain; charset=ISO-8859-1; format=flowed
  
  Salut,
  
  Le 15/11/2012 14:22, Colin Durand a écrit :
   Bonjour,
  
   Je viens de m'inscrire sur cette liste après avoir vu que certaines 
   personnes cartographiaient la frontière Guyane / Brésil le long du fleuve 
   Oyapoque. J'étais en train de faire la même chose de l'autre coté sur la 
   frontière Suriname / Guyane, le long du fleuve Maroni après avoir bossé 
   là bas il y a quelques temps déjà.
  
   Je cartographie principalement les iles et bras du Fleuve. Pour ce qui 
   est de la frontière je ne m'amuse pas à la déplacer en sachant que la 
   frontière sur cette zone n'est pas bien définie, il est par exemple 
   impossible de savoir si certaines îles sont françaises ou surinamaise. 
   Pour ce qui est du nom de tous les villages / hameau le long de ce fleuve 
   nous en avions fait une carte exhaustive pour une bonne partie du fleuve 
   Maroni mais largement basée sur les orthophotographies de l'ign je ne 
   peux donc pas l'utiliser directement car basée sur des données non 
   libres. Il faudrait que je réfléchisse à faire en sorte de l'utiliser 
   dans la règles, dans ce cas la Open Street Map deviendrait sans problème 
   la carte la plus précise sur la zone, la dernière de l'IGN doit dater des 
   années 60 sauf si elle a été reprise récemment.
  
   Pour la précision des images, les images bing sont celles de l'IGN qui si 
   elles ne sont pas trop modifiées c'est ce qu'il y a de plus précis pour 
   la guyane
  
   Et, une petite interrogation, ceux qui travaillent sur ces zones, savez 
   vous comment caractériser les camps d'orpaillage ?
  
   Bonne soirée,
  
   Colin.
  
  Bienvenue ;-)
  Vais me sentir moins seul !
  Tu as dû constater que j'avais retaillé beaucoup les riverbanks des 
  grands fleuves, dont le Maroni jusqu'à grosso modo Maripasoula 
  (contributeur Stephixus).
  Si j'ai fait des conn, pas hésiter à me le dire !
  
  Me suis attaqué à l'Oyapock et c'est loin d'être fini :-(
  Le tout à partir de Bing.
  
  Pas possible de replacer les villages du fleuve avec Bing ? Pas visibles ?
  Si tu as besoin d'un coup de main pour de 

Re: [OSM-talk-fr] Noms de magasins supprimés

[Vladimir Vyskocil]

Le 14 nov. 2012 à 20:24, Christian Quest cqu...@openstreetmap.fr a écrit :

 J'ai vu que tu avais fais les revert... merci WHODIDIT qui me l'a signalé sur 
 Disneyland Paris ;)
 

Oui, car j'ai contacté ce contributeur indélicat et pour seul réponse j'ai vu 
qu'il avait continué son massacre des noms. Par exemple il ne semble pas 
supporter l'idée que le nouveau stade de Nice s'appelle maintenant «Allianz 
Riviera» et pas «Le Grand Stade de Nice en construction», que MacDonald's 
s'affiche sur la carte (ainsi que beaucoup d'autres), etc,...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Noms de magasins supprimés

[Vladimir Vyskocil]

Il a un TOC ce contributeur ? 
Ce n'est pas qu'à Nice qu'il a supprimé un tas de noms et autres informations !

Envoyé de mon iPad

Le 11 nov. 2012 à 13:18, Fabien SK fabie...@gmail.com a écrit :

 Bonjour,
 
 Je viens de me rendre compte qu'un utilisateur (AD06) a supprimé un
 grand nombre de noms (et autres tags) de magasins niçois (ce qui me fout
 un peu les boules vu le temps passé dans la rue à noter sur mon
 téléphone), et malheureusement sans commentaire. On peut le remarquer en
 regardant l'historique des nœuds ayant plus d'une version, par exemple à
 partir de ce changeset:
 
 http://www.openstreetmap.org/browse/changeset/13005326
 
 Je viens de lui envoyer un message. Y a-t-il autre chose qu'il serait
 possible de faire?
 
 Fabien
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Noms de magasins supprimés

[Vladimir Vyskocil]

À y regarder de plus près je pense qu'il supprime certains noms pour que 
d'autres soient visibles sur le rendu mapnik !

Le 11 nov. 2012 à 20:16, Vladimir Vyskocil vladimir.vysko...@gmail.com a 
écrit :

 Il a un TOC ce contributeur ? 
 Ce n'est pas qu'à Nice qu'il a supprimé un tas de noms et autres informations 
 !
 
 Envoyé de mon iPad
 
 Le 11 nov. 2012 à 13:18, Fabien SK fabie...@gmail.com a écrit :
 
 Bonjour,
 
 Je viens de me rendre compte qu'un utilisateur (AD06) a supprimé un
 grand nombre de noms (et autres tags) de magasins niçois (ce qui me fout
 un peu les boules vu le temps passé dans la rue à noter sur mon
 téléphone), et malheureusement sans commentaire. On peut le remarquer en
 regardant l'historique des nœuds ayant plus d'une version, par exemple à
 partir de ce changeset:
 
 http://www.openstreetmap.org/browse/changeset/13005326
 
 Je viens de lui envoyer un message. Y a-t-il autre chose qu'il serait
 possible de faire?
 
 Fabien
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk] Data copied from Google Maps

[Vladimir Vyskocil]

On 5 nov. 2012, at 23:39, Cartinus carti...@xs4all.nl wrote:

 Copyright has absolutely nothing to do with this at all. All arguments
 people use in this this discussion in relation to copyright are just a
 smokescreen to try to get their way.
 
 When viewing Google StreetView you are using a service from Google. The
 rules in relation to that, are the rules for business transactions, not
 those of copyright.
 
 Just like Openstreetmap has rules that say you are not allowed to scrape
 tiles from our tileserver, Google has rules that say when you are
 allowed to use their services.

Yes and they say I'm not allowed to copy all or parts of the provided material 
(images,...) and also that I can't make derivative work. When I interpret what 
I can see in Street View photos and write it down I'm doing neither of these ! 

 
 
 
 On 11/05/2012 11:25 PM, Vladimir Vyskocil wrote:
 Hi,
 
 According to : http://en.wikipedia.org/wiki/Derivative_work
 
 In United States copyright law, a derivative work is an expressive creation 
 that includes major, copyright-protected elements of an original, previously 
 created first work (theunderlying work).
 
 Obviously looking at google street view images and noting some facts we can 
 see in them like street names,... can't be seen as derivative work. 
 
 And : 
 
 
 When does derivative-work copyright exist?
 For copyright protection to attach to a later, allegedly derivative work, it 
 must display some originality of its own. It cannot be a rote, uncreative 
 variation on the earlier, underlying work. The latter work must contain 
 sufficient new expression, over and above that embodied in the earlier work 
 for the latter work to satisfy copyright law’s requirement of originality.
 
 
 It's clear that Google's photos in street view have no originality at all, 
 they are just facts. Using some information everybody can see in those 
 images isn't a creative process either. 
 
 In the light of those definitions of derivative work, I can't understand how 
 one might see a infringement of google terms of use when OSM contributors 
 look at Google Street View photos to verify some facts (street names, signs, 
 ...)
 
 Regards,
 Vlad. 
 
 Le 5 nov. 2012 à 16:42, Frederik Ramm frede...@remote.org a écrit :
 
 Hi,
 
  I haven't read this thread in full but it has come to my attention that 
 people in this thread have argued that it would be acceptable to use Google 
 StreetView pictures when mapping.
 
 It is not.
 
 The legal situation may be debatable and indeed differ from country to 
 country but Google's terms of use do not permit making derivative works of 
 their imagery and distributing them.
 
 As a project, our general approach to any situation where something was not 
 totally clear legally has always been to err on the side of caution. If 
 someone says that we cannot use this data then we won't, even if there are 
 people who say that it might still be legal to do so.
 
 So don't use Google Street View for mapping unless you have explicit 
 permission from Google to do so.
 
 Bye
 Frederik
 
 -- 
 Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 
 
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
 
 
 -- 
 ---
 m.v.g.,
 Cartinus
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk] Data copied from Google Maps

[Vladimir Vyskocil]

 
 After searching in taginfo, I found all these other
 instances of data copied from Google, such as some data in Paris that
 was tagged as coming from Google Street View (I deleted it).

Vandal !

 
 I have contacted the Data Working Group, they ought to do a better job
 deleting the data than I can.
 

Vlad.

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

Re: [OSM-talk] Data copied from Google Maps

[Vladimir Vyskocil]

Hi,

According to : http://en.wikipedia.org/wiki/Derivative_work

In United States copyright law, a derivative work is an expressive creation 
that includes major, copyright-protected elements of an original, previously 
created first work (theunderlying work).

Obviously looking at google street view images and noting some facts we can see 
in them like street names,... can't be seen as derivative work. 

And : 


When does derivative-work copyright exist?
For copyright protection to attach to a later, allegedly derivative work, it 
must display some originality of its own. It cannot be a rote, uncreative 
variation on the earlier, underlying work. The latter work must contain 
sufficient new expression, over and above that embodied in the earlier work for 
the latter work to satisfy copyright law’s requirement of originality.


It's clear that Google's photos in street view have no originality at all, they 
are just facts. Using some information everybody can see in those images isn't 
a creative process either. 

In the light of those definitions of derivative work, I can't understand how 
one might see a infringement of google terms of use when OSM contributors look 
at Google Street View photos to verify some facts (street names, signs, ...)

Regards,
Vlad. 

Le 5 nov. 2012 à 16:42, Frederik Ramm frede...@remote.org a écrit :

 Hi,
 
   I haven't read this thread in full but it has come to my attention that 
 people in this thread have argued that it would be acceptable to use Google 
 StreetView pictures when mapping.
 
 It is not.
 
 The legal situation may be debatable and indeed differ from country to 
 country but Google's terms of use do not permit making derivative works of 
 their imagery and distributing them.
 
 As a project, our general approach to any situation where something was not 
 totally clear legally has always been to err on the side of caution. If 
 someone says that we cannot use this data then we won't, even if there are 
 people who say that it might still be legal to do so.
 
 So don't use Google Street View for mapping unless you have explicit 
 permission from Google to do so.
 
 Bye
 Frederik
 
 -- 
 Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Route saisonnière

[Vladimir Vyskocil]

On 29 sept. 2012, at 20:03, Eric SIBERT courr...@eric.sibert.fr wrote:

 Bonsoir,
 
 Je cherche comme indiquer qu'une route est à ouverture ou fermeture 
 saisonnière. Typiquement, les cols de montagne qui sont fermés en hiver. 
 Jusqu'à présent, je mettais opening_hours avec une valeur du style Nov-Apr 
 off. Mais je me demandais s'il y avait un moyen plus générique d'indiquer 
 que c'est saisonnier avec un aspect aléatoire.
 
 J'ai vu qu'il y avait une proposition seasonal=* :
 http://wiki.openstreetmap.org/wiki/Key:seasonal
 
 Usage en Europe : yes (497), no (19), winter (12), summer (9), * (2), Spring, 
 Summer, Fall (1), Yes (1)
 
 Le même problème se pose en Afrique avec les pistes impraticables en saison 
 des pluies.
 
 Usage en Afrique : year_round (171), yes (75), wet_season (32), 
 cannot_determine (27), another_pattern (16), dry_season (7), na_dn (1), 
 dry_weather (1)
 
 En plus, en Afrique, la piste peut ne pas être fermée mais c'est juste le 
 type de véhicule qui peuvent l’emprunter qui change. Ça reviendrait à ne pas 
 avoir la même valeur pour la clé smoothness=* suivant la saison.
 
 D'autres propositions?

Au Costa Rica ils ont trouvé une solution, le nom du track ou même de la 
route contient 4wd only ;-)

 
 -- 
 Éric
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Contributeur hyperactif mais pas très précis

[Vladimir Vyskocil]

On 3 oct. 2012, at 13:58, te...@free.fr wrote:

 Euh, juste une question : ça fait combien d'années qu'on n'utilise plus le 
 tag oneway=-1 qui, s'il faut le rappeler, caractérise une voie en sens 
 unique dans le sens __opposé__ à celui suivi par les nœuds ?

Malheuseument (ou heureusement ?) dans JOSM si on inverse le sens d'une voie, 
par exemple pour combiner deux tronçons, ou juste pour le plaisir,... si la 
voie en question possède des tag qui sont dépendants de l'ordre des noeuds 
(restrictions pour tourner a droite, a gauche,..., voie pour les vélos d'un 
coté, ) le logiciel propose d'utiliser oneway=-1 pour s'en sortir sans 
toucher aux tags pré-cités, enfin c'est comme cela que je l'ai compris.

 
 Teuxe
 
 - Mail original -
 De: Eric SIBERT courr...@eric.sibert.fr
 À: talk-fr@openstreetmap.org
 Envoyé: Mardi 2 Octobre 2012 18:52:14
 Objet: Re: [OSM-talk-fr] Contributeur hyperactif mais pas très précis
 
 Il ne m'a pas répondu, et continu à tracer des routes comme un fou avec
 Potlatch.
 [...]
 A recent example :
 http://www.openstreetmap.org/?lat=46.940197lon=-1.07499zoom=18layers=M
 
 Il n'y a pas que le fait qu'il trace à la hache. Dans l'exemple proposé 
 un rond-point n'est pas codé comme tel. Légèrement au nord, il a tracé 
 une route par dessus un chemin agricole déjà tracé. Un peu plus loin, 
 sur un rond-point existant, il a rajouté oneway = -1 là où on 
 attendait junction=roundabout. Bizarre aussi la Rue des Bois avec 
 trois branches.
 
 N'hésite pas à faire preuve de pédagogie ;-), éventuellement en 
 français, vu qu'il code en zone francophone.
 
 Éric
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

[OSM-talk-fr] Un peu de stats sur le bâti importé

[Vladimir Vyskocil]

Je me suis demandé quelle est la première ville Française par ordre 
d'importance (liste ordonnée dans wikipedia : 
http://fr.wikipedia.org/wiki/Ville_de_France) qui n'a pas encore le bati 
(provenant du cadastre ou pas) semblant plus ou moins exhaustif à vu d'oeil.
J'ai eu beau chercher mais je n'ai pas eu la réponse en parcourant les 50-60 
premières villes de la liste qui semblent toutes complètes, ensuite j'ai 
regardé en peu au hasard dans la liste mais à chaque fois le cadastre etait la !
C'est la que je me suis fait la réflexion que l'importation du cadastre avait 
sacrement pris un coup d'accélérateur cette dernière année, non ?
Existe t'il des stats plus précises ?

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

Re: [OSM-talk-fr] Premières modifications suspectes

[Vladimir Vyskocil]

Bonjour,

Par hasard ceci ne serait pas lié à la suppression de la ligne de côte en 
double et de la fermeture de la réserve naturelle dans le Morbihan dont on a 
parlé hier sur la liste ?

Vlad.

On 1 oct. 2012, at 09:27, Ab_fab gamma@gmail.com wrote:

 Bonjour,
 
 Je manque de temps pour regarder dans les détails et éventuellement pour 
 corriger, mais je trouve qu'il y a beaucoup d'effacements pour ce premier 
 changeset de nouveau contributeur :
 http://www.openstreetmap.org/browse/changeset/13316338 
 
 @+
 -- 
 ab_fab
 Il n'y a pas de pas perdus
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Problème de trait de côte près de Vannes

[Vladimir Vyskocil]

On 30 sept. 2012, at 13:31, Philippe Verdy verd...@wanadoo.fr wrote:

 Si tu veux t'amuser, regarde plutôt du côté de la Méditerranée,
 particulièrement la côte du Languedoc-Roussillon, où les traits se
 juxtaposent sans logique autour de la ligne de côte, elle aussi très
 imprécise mais qui devrait pourtant une fois affinée servir de
 frontière des communes, arrondissements, départements et régions.

Oui j'ai déjà regardé et cela me désespère ! J'ai fait des corrections en 
partant de l'est mais j'ai abandonné vers Toulon...
De plus je me suis rendu compte que je n'ai pas fait que des corrections 
correctes, notamment au niveau des ports que j'ai creusé avec la ligne de 
côte ou avant l'eau n'était symbolisée que par le tag leisure=marina, mais j'ai 
également fait suivre  la ligne de côte aux limites administrative, excluant la 
surface de la partie marine du port, ce qui me semble faux maintenant...
Pour en revenir au Morbihan, je suis tombé par hasard sur cette erreur en 
regardant le site qui donne les erreurs actuelle sur la coastline.
Et contrairement a la superposition approximative des différentes lignes 
administratives, natural=coastline,... du Languedoc-Roussillon dans le Morbihan 
il y a un vrai problème avec 2 lignes qui possédent le tag natural=coastline 
qui se chevauchent sur des kiliometres.
De plus une des lignes de côte s'arrête brusquement au point rouge sur la carte 
de mon précédent mail.

 
 Le 29 septembre 2012 18:20, Vladimir Vyskocil
 vladimir.vysko...@gmail.com a écrit :
 Hep les Bretons, il y a un truc bizarre de ce coté la :
 
 http://wightpaths.co.uk/coast/?zoom=18lat=47.62088lon=-2.86987layers=B
 
 Il y a un trait de côte (natural=coastline) quasiment superposé sur une 
 longue distance avec des limites administratives qui ont aussi le tag 
 natural=coastline !
 On fait quoi la ?
 
 Vlad.
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] Problème de trait de côte près de Vannes

[Vladimir Vyskocil]

On 30 sept. 2012, at 16:08, panierAvide panierav...@laposte.net wrote:

 Le 30/09/2012 15:42, Vladimir Vyskocil a écrit :
 Et contrairement a la superposition approximative des différentes lignes 
 administratives, natural=coastline,... du Languedoc-Roussillon dans le 
 Morbihan il y a un vrai problème avec 2 lignes qui possédent le tag 
 natural=coastline qui se chevauchent sur des kiliometres. De plus une des 
 lignes de côte s'arrête brusquement au point rouge sur la carte de mon 
 précédent mail.
 Je serai d'avis de laisser uniquement le natural=coastline sur la limite 
 administrative, les limites communales ont moins de chances de bouger que la 
 réserve naturelle. Et pour la zone montrée dans le premier message, mettre 
 natural=coastline sur le chemin 35210592 (limite administrative à l'est), et 
 sur les chemins 35210599 et 35212411. Et pour finir, fermer la réserve 
 naturelle, à laquelle il manque un morceau. Je m'en occupe ?

Ok, je n'y voit pas d'inconvénient.

Vlad.

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


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

[OSM-talk-fr] Problème de trait de côte près de Vannes

[Vladimir Vyskocil]

Hep les Bretons, il y a un truc bizarre de ce coté la :

http://wightpaths.co.uk/coast/?zoom=18lat=47.62088lon=-2.86987layers=B

Il y a un trait de côte (natural=coastline) quasiment superposé sur une longue 
distance avec des limites administratives qui ont aussi le tag 
natural=coastline !
On fait quoi la ?

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

[Vladimir Vyskocil]

 
  The larger part of cadastre data
 is just dumped into the data base never to be touched again by any mapper.

That's also wrong, the french community has developed some very powerful  tools 
like osmose.openstreetmap.fr which is used to automatically discover many 
errors from cadastre and others, it's used along the import process by many 
people to locate and fix many bugs, for example here is a search focused on 
some errors that we seek :

http://osmose.openstreetmap.fr/map/?zoom=12lat=45.22034lon=5.74928layers=B00FF0FFTitem=0,1040,3091level=1

Osmose is going worldwide for some analysis, so other community will benefit 
from this great tool.
There are also many go and return between data from cadastre and already in 
place data like roads and POI, the locations of each objects is used to improve 
the global accuracy (also with the help of other source : Bing,...). I 
discovered and fixed many roads and POI  with the help of the building 
footprints, in the process I try also to fix errors on cadastre that I can 
spot, some split buildings from time to time,...
Very often I can spot isolated buildings imported from cadastre and make search 
how to map the missing roads.
There are also IGN (french geomatic institute) landmarks which have been 
imported in the base, they are very accurately positioned reference physical 
points like the cross of church,... They are often used to precisely fix the 
location of the cadastre data if needed.

 
 no addresses or names or pois. It is rather ugly for rendering, there are
 no real buildings just unspecific building parts and way too much detail
 (small round edifices using up 40 nodes, what for?). You cannot do real
 statistics on them, there are just unspecific building parts...
 So essentially alomost every data user has to go through 25 million 
 buildings just to throw them away. It is not the end of the world,
 but it is mildly annoying.

I don't agree  the cadastre is ugly once rendered ! A rendered map like this 
for example, is in my opinion something more pleasant than a map with only a 
house once and there with large holes :

http://www.openstreetmap.org/?lat=43.70272lon=7.26654zoom=15layers=Q

This data is also beautifully used by the community behind 3D rendered map used 
in X-Plane flight simulator. 3D maps is something on the rise and detailed 
buildings are needed for this !

Regards,
Vlad.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

[Vladimir Vyskocil]

 
 There are some excellent examples of how mapping should be done all over the 
 world. But I do hope we have shown that a large percentage of the data STILL 
 needs a lot of work? At the end of the day this is more about education of 
 mappers and how to get the best out of the material available. In hindsight I 
 think there is some agreement that perhaps the data should not have been made 
 'generally' available and that mappers were monitored a little more as to 
 their use of the data? The horse has bolted now, so tools to clean up are now 
 needed :(
 
 In SOME areas the cadastre is ugly with several strange shaped blocks sort of 
 grouped together vaguely around the location of a clean square building on 
 the imagery ... that is what is irritating ...
 

Yes it's the actual situation, it is like some other big imports : TIGER, PGS 
coastline,..., it's a work in progress and the community is improving things, 
it's OpenStreetMap !
I think OSM is better with this data in than without.

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

Re: [OSM-talk] All you've ever wanted to know about the french cadastre

[Vladimir Vyskocil]

On 27 sept. 2012, at 14:04, Lester Caine les...@lsces.co.uk wrote:

 Now that I have scanned some of the French material I must say that it is of 
 very low quality and all of the stuff I have reviewed needs at least SOME 
 work to bring it up to a better standard. At best all one can say currently 
 is 'there are some buildings round about here' ... and stripping 
 unsubstantiated detail would at least be a start.

At least the quality of the French Cadastre is way better than, say... Tiger 
data that was imported almost straight to the base and that is still in most 
part untouched by OSM contributors !

Vlad.


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

Re: [OSM-talk] Bad (wrong?) OSM publicity?

[Vladimir Vyskocil]

Here in France, we can read similar complains about  poor quality Apple's iOS6 
map data coming from OSM ! 
A lot of people are convinced that the bad state of the Apple data is related 
to the usage of source like OSM...
But it seems that Apple is using very few, perhaps nothing from OSM for the 
french area, even more, if they have used OSM data the quality of their maps 
would have increased !

Vlad.


On 25 sept. 2012, at 07:32, Martijn van Exel m...@rtijn.org wrote:

 From 
 https://www.nytimes.com/2012/09/25/technology/apple-maps-errors-send-japanese-to-homegrown-app.html?emc=tnttntemail0=y_r=0moc.semityn.www
 
 The biggest problem with Apple’s map, Mapion’s Mr. Yamagishi said, is
 that much of its data appears to be drawn from OpenStreetMap Japan, a
 Wikipedia-like service that contains a lot of incorrect and outdated
 information.
 
 1) Is Apple using OSM data for Japan?
 2) If they are, I can't believe this is a correct statement.
 
 -- 
 martijn van exel
 http://oegeo.wordpress.com
 
 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk


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

Re: [OSM-talk-fr] Imports du cadastre et compte dédié

[Vladimir Vyskocil]

Hier soir, en faisant une correction ou deux pour le Remap-O-Tron qui a pour 
but de re-cartographier les données supprimées sur les USA après le changement 
de licence, je suis encore tombé sur des zones avec des données importées de la 
base Tiger complètement farfelues qui n'ont jamais été touchées par un 
contributeur OSM (comme un très fort pourcentage des données la bas)
Je me suis demandé comment on avait pu laisser faire un import aussi brut et de 
mauvaise qualité directement dans la base (avec un compte séparé, il est vrai 
;-) et surtout comment on pouvait autant critiquer l'intégration de notre 
cadastre qui semble bien mieux maitrisé et d'une qualité qui n'a rien a voir...
Mais bon cela ne m'empêche pas d'aller donner un coup de main la bas, ils en 
ont bien besoin ;-)

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

Re: [OSM-talk-fr] OpenStreetMap et iOS 6

[Vladimir Vyskocil]

Bizarrement on dirait que dans l'opinion de certains les problèmes de 
cartographie d'Apple soit imputables à l'utilisation d'OpenStreetMap ! 
Voir les commentaires de ce blog par exemple : 

http://www.journaldulapin.com/2012/09/23/plans-sous-ios-6-et-le-scuffgate-de-liphone-5/

Vlad.


On 22 sept. 2012, at 00:15, Emilie Laffray emilie.laff...@gmail.com wrote:

 Et aussi que sur certains produits.
 Le problème d'ios 6 serait un mélange de données teleatlas retraité par Apple.
 

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

Re: [OSM-talk-fr] nommage des routes

[Vladimir Vyskocil]

En parlant de nommage bizarre j'ai vu récemment des ref commençant par M, 
comme ici par exemple : 

http://www.openstreetmap.org/?lat=43.69491lon=7.19316zoom=15layers=M

Je l'ai également constaté sur le terrain. 
Est-ce que ce M est nouveau ? Cela veut t'il dire Municipale ?

Vlad.


On 23 sept. 2012, at 20:23, Michaël Zakrzewski mikamika48197...@free.fr wrote:

 Bonjour,
 
 en ce qui concerne le nommage des routes, est-ce que l'utilisation des images 
 Google Street view est autorisée ?
 
 Dans ce cas, est-ce qu'il est pertinent de nommer les embranchements (c'est 
 bien ça les D2e3) des départementales ?
 
 comme là où il y a à priori des erreurs de panneaux http://goo.gl/maps/blrK1  
 http://goo.gl/maps/TXpCS
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr


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

Re: [OSM-talk-fr] nommage des routes

[Vladimir Vyskocil]

On 24 sept. 2012, at 21:18, Romain MEHUT romain.me...@gmail.com wrote:

 M pour Métropolitaine cf. 
 http://lists.openstreetmap.org/pipermail/talk-fr/2012-June/044552.html

Ah merci, j'avais loupé ça ! 
Alors que l'on a encore plein d'anciennes nationales qui n'ont pas été 
corrigés dans OSM il  ne nous manquait plus que ça... 

 
 Romain
 
 Le 24 septembre 2012 21:13, Vladimir Vyskocil vladimir.vysko...@gmail.com a 
 écrit :
 En parlant de nommage bizarre j'ai vu récemment des ref commençant par M, 
 comme ici par exemple :
 
 http://www.openstreetmap.org/?lat=43.69491lon=7.19316zoom=15layers=M
 
 Je l'ai également constaté sur le terrain.
 Est-ce que ce M est nouveau ? Cela veut t'il dire Municipale ?
 
 Vlad.
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Potlatch, utilisable avec le cadastre ? [Etait : Potlatch, mauvais outil ?]

[Vladimir Vyskocil]

Le 7 sept. 2012 à 19:30, Philippe Verdy verd...@wanadoo.fr a écrit :

 C'est comme le HTML, CSS, Javascript... Pire encore maintenant avec
 HTML5 et les restrictions propriétaires et licences de brevets dessus
 (sans compter des tas de brevets dont personne n'a encore eu jamais
 connaissance et qui sortent régulièrement, même la licence MPEG LA
 sensée les couvrir tous en une seule fois pour les codecs
 audio/vidéo/image ne couvre pas tout).

Ma chère et tendre, qui travaille au W3C va être désolée d'apprendre cela !
Plus sérieusement je pense que la situation est bien plus saine maintenant avec 
HTML5 qu'avant avec le web dédié à Microsoft/IE6 et ses incompatibilités 
parfois totale avec les autres navigateurs ET OS, le flash propriétaire, 
optimisé sur Windows mais mal supporté ailleurs,...

Vlad. 

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

Re: [OSM-talk-fr] Frontières de Madagascar cassées

[Vladimir Vyskocil]

Hello,

J'ai également vu ça et il y a d'autres endroits ou c'est le cas (amérique 
centrale par exemple), il me semble que c'est du au changement de licence, en 
tout cas c'est ce que j'ai vu du coté du Costa Rica ou j'ai pu remettre un bout 
avec les noeuds orphelins qui restaient mais il reste (je n'ai pas vérifié très 
récement alors c'est peut etre réglé de ce coté la) de large portions 
manquantes.

Vlad.

On 5 sept. 2012, at 14:26, Arnaud Vandecasteele arnaud@gmail.com wrote:

 Salut à tous,
 
 
 En me baladant sur la carte d'OSM, j'ai remarqué une anomalie.
 En effet, au niveau de zoom 4 la frontière (limite des eaux territoriales ?) 
 de Madagascar semble cassée :
 http://www.openstreetmap.org/?lat=-20.302734375lon=53.349609375zoom=4
 
 A un niveau de zoom inférieure, cela est correct.
 
 Marc, je crois que tu bosses pas mal sur cette zone non ?
 Tu auras certainement un meilleur regard que moi.
 
 Arnaud
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Osmecum aux champs pour la randonnée à pied, à vélo ou à cheval

[Vladimir Vyskocil]

Le 20 juin 2012 à 10:41, Gilles Bassière gbassi...@gmail.com a écrit :

 Salut Romain,
 
 Merci de partager ce document.
 
 Mes remarques/suggestions :
 
 * Ça n'est pas génial de mélanger path et footway.

En fait highway=footway n'est qu'un raccourci pour highway=path, 
foot=designated (idem pour cycleway et bridleway qui sont bicycle=designated 
et je sais plus quoi cheval designated). Ces raccourcis ne sont que les 
vestiges de l'ancien schéma pour tagguer les chemins, highway=path étant la 
façon moderne. 

 Je pense qu'il vaut
 mieux en choisir un des deux, ça simplifiera le travail des utilisateurs
 de ton Osmecum (surtout s'ils sont novices). Reste à choisir lequel des
 deux, il n'y a pas de consensus dans la communauté à ma connaissance...
 
 * J'aurais mis barrier=* dans la section restriction d'accès puisqu'il
 peut y avoir des barrier=* sur tous types de chemin (et même hors
 chemin). Dans la description, je parlerais plutôt de constructions
 restreignant l'accès (obstacle me paraît trop flou, voire trompeur).
 
 * smoothness=* me semble plus indiqué pour les véhicules motorisés que
 pour les randonneurs. Mais puisque c'est sur le même terrain, on peut le
 noter au passage, effectivement. Est-ce que ça ne risque pas de
 perturber des contributeurs peu expérimentés ?
 
 * Je connaissais incline=up|down (surtout pour les escaliers). Je
 découvre qu'on peut y mettre des valeurs en % ou °. Peut-être faut-il
 préciser quelle type de valeur est attendue ?
 
 * Pour le balisage, je mets trailblazed=yes|no sur le way d'habitude,
 pas sur la relation route (il y a déjà osmc:symbol sur la relation). Sur
 le way, je mets également systématiquement hiking=yes aussi.
 
 * Mettre les valeurs possibles et les critères pour les attributs
 subjectifs apporterait un plus. Pour sac_scale par exemple :
 hiking - ça passe pour la balade digestive du dimanche avec belle-maman
 mountain_hiking - chaussures de marche, des raidillons, un peu d'effort
 demanding_mountain_hiking - marcheur régulier, passages aériens
 alpine_hiking - ...
 C'est vraiment sur le terrain qu'il faut avoir ces critères en tête pour
 observer et noter.
 J'indiquerais aussi les critères pour tracktype, trail_visibility et
 smoothness. Pour barrier et surface, ça peut être bien de connaître sur
 le terrain les valeurs possibles aussi, même si c'est moins subjectif.
 
 Cordialement
 Gilles
 
 Le mercredi 20 juin 2012 à 07:51 +0200, Romain MEHUT a écrit :
 Bonsoir,
 
 Comme indiqué dans un autre (très discuté [1]) fil de discussion,
 j'avais préparé un Osmecum en préparation de la cartopartie randonnée
 organisée samedi dernier à Abbaretz (44) par le Conseil Général. Suite
 à la cartopartie, je l'ai complété avec quelques éléments
 supplémentaires. Il est en partage ici.
 
 Aussi, je n'ai pas manqué d'indiquer une note concernant la
 spécificité franco-française des itinéraires balisés de la FFRP...
 
 Je n'ai pas encore posté l'osmecum sur la page du wiki, je souhaite
 recueillir vos avis et propositions de modifications si besoin...
 
 Merci.
 
 Romain
 
 [1] au vu de ce fil, je crois qu'il n'est pas nécessaire que je
 m'étende davantage sur un compte-rendu de la cartopartie où les
 randonneurs du comité départemental se sont montrés très intéressés et
 finalement pas offusqués que des GR puissent être dans OSM. Si on
 arrive à convaincre plusieurs comités départementaux qu'OSM peut être
 un complément pour eux vis à vis des cartes IGN, la fédération
 pourrait ainsi prendre plus facilement position. 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr
 
 
 -- 
 Gilles Bassière - Web/GIS software engineer
 http://gbassiere.free.fr/
 
 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Communauté de Commune du Nord de la Réunion

[Vladimir Vyskocil]

Bonjour,

Je saute sur l'occasion de cet exemple pour poser une question : est-ce qu'il y 
aurait une méthode rapide (donc simple, ou vice-versa) pour découper les 
landuses (forêts,...) au niveau de la ligne de côte pour éviter qu'ils 
débordent dans l'océan comme c'est le cas ici (et souvent ailleurs) ?

Et sinon bravo pour l'avancement de la cartographie de la Réunion ou j'avais 
également un peu participé suite a un voyage (j'ai vu hier que j'avais encore 
la 6eme place, quand meme ! ;-)

On 21 août 2012, at 13:42, Arnaud Vandecasteele arnaud@gmail.com wrote:

 Salut à tous,
 
 Avant de commencer le travail de suppression du tag, je souhaiterais savoir 
 si je dois (peux) également nettoyer la couche coastline.
 En effet, à certains endroit elle est particulièrement morcelée.
 
 Ex :
 
 http://www.openstreetmap.org/browse/way/70954343
 ou encore
 http://www.openstreetmap.org/browse/way/86303618
 
 Cela vaut-il le coup ?

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

Re: [OSM-talk-fr] Venise bien abimée par le changement de licence...

[Vladimir Vyskocil]

 
 Je viens d'y passer et effectivement il y a beaucoup de rouge sur le rendu de 
 geofabrik. J'ai fait un petit bout de correction, juste pour voir.

J'ai également réparé des trucs, notamment la ou je connais un peu mais aussi 
ailleurs ou l'imagerie de Bing permet de bien voir (heureusement c'est assez 
précis sur la ville). 
Il y a également des trucs évidents comme ajouter area=yes sur les places qui 
ne l'avaient pas.
J'ai remarqué que précédemment les voies piétonnes étaient mappé en footway 
(highway=path, foot=designated) et que maintenant c'est plutot des 
highway=pedestrian ce qui me semble plus approprié dans le cas général.

 
 Plutôt que de geindre sur le passé, il ne reste qu'à se retrousser les 
 manches et filer un coup de main aux italiens qui seront content de recevoir 
 de l'aide.
 A noter quand même que le bâti à l'air intact

Presque, j'ai du remettre des batiments qui avaient disparus mais globalement 
c'est vrai.

 et maintenant que l'on sait que la rue c'est bien l'espace entre les 
 immeubles non ? -- hamster ML 25/06/2010 (from 
 http://wiki.openstreetmap.org/wiki/FR:Fortunes), ça va être plus facile 
 d'avancer, quoi qu'à Venise il faut se méfier des canaux.
 
 N'hésitez pas à répondre dans ce fil si vous êtes intéressés.
 
 A+
 
 Marc
 -- 
 Marc Sibert
 mailto:m...@sibert.fr
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] Venise bien abimée par le changement de licence...

[Vladimir Vyskocil]

Je me souviens avoir utilisé la carte il y a quelques années lors d'un 
voyage...après le passage du bot cela doit être bien plus difficile :

http://tools.geofabrik.de/osmi/?view=redactionbotlon=12.33321lat=45.43687zoom=15opacity=0.73overlays=overview,bot_point_superseded,bot_line_superseded_cp,bot_line_superseded,bot_point_modified,bot_line_modified_cp,bot_line_modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted

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