Re: [OSM-talk-fr] Smartphone low cost à conseiller pour cartographier ?

[Christian Quest]

J'ai acheté un Wiko Cink Slim* pour tester (et aussi pour essayer les
applis Android pour OSM).

Premier constat: il reste effectivement peu de stockage libre (1,5Go),
surtout si on charge un peu la bestiole avec des cartes pour OsmAnd.
Donc besoin d'ajouter une microSD... 10 euros pour 8Go, 40 euros pour 32Go
(le maximum pour ce smartphone, c'est ce que j'ai mis).

Je l'ai utilisé sans carte SIM, donc connecté par wifi (soit à ma box, soit
en partage 3G via mon iPhone).

Il est rapide et agréable à utiliser, le GPS met du temps à se caler
(normal, sans carte SIM, pas de A-GPS), mais une fois calé il a une
précision tout à fait classique et comparable avec la majorité des GPS.

Pour les photos, ça va très bien aussi, même si le déclenchement uniquement
via une touche sur l'écran est quand même moins pratique que via le bouton
de volume de l'iPhone.
Capteur assez sensible et rapide, donc des photos nettes même avec une
mauvaise lumière et il gère plutôt bien les contre jour quand on règle sa
mesure d'exposition en "centrale" (chose que je ne peux pas faire sur mon
iPhone).

Côté abonnement 3G, je vais tester le forfait Idol à 9,99€/mois de Virgin
Mobile (3G illimitée avec 1Go de fair use + 1h d'appels et le tout sans
engagement) et voir ce que donne le A-GPS.

Bref, pour 150 euros en comptant la microSD, ça tient la comparaison avec
mon iPhone 4 et ça me semble un très bon outil pour les relevés sur le
terrain.


* en blanc... comme ça l'autocollant OSM semble d'origine ;)
-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon :
http://openstreetmap.fr/s
ynthese-sotmfr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Smartphone low cost à conseiller pour cartographier ?

[Lapinos03]

Pour 30€ de plus, le Wiko Cink Peax, dernier né de la gamme, en offre plus :
- écran plus grand (4"5)
- résolution plus fine (qHD)
- double de RAM : 1Go (un gros plus pour Android 4.0 et supérieur)
- batterie un peu plus grande
- un peu plus léger

Pourquoi s'en priver à ce prix-là ?

@+


Le 30/03/13 10:39, Christian Quest a écrit :
J'ai acheté un Wiko Cink Slim* pour tester (et aussi pour essayer les 
applis Android pour OSM).





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

Re: [OSM-talk-fr] Licence IP et ODBL ( était : L'ON3V libère ses donnés?)

[Brice Person]

Bonjour,

On 29/03/2013 21:13, Vincent de Chateau-Thierry wrote:

Bonsoir,

Le 29/03/2013 19:54, sly (sylvain letuffe) a écrit :

On vendredi 29 mars 2013, Romain MEHUT wrote:
Par contre quelqu'un d'autre a indiqué que la licence IP serait 
incompatible
avec l'Open Data étant donné la clause de non altération. Est-ce 
vraiment un
élément qui rend incompatible ces données pour une réutilisation 
dans OSM?


Et j'emmétrais moi même un fort doute.
En effet, si la licence IP oblige une "non altération" des données, 
cela n'en
fait plus une licence libre, et donc, elle n'est plus compatible avec 
ODBL.


C'est la conclusion que nous avions eu à l'époque de sa sortie. De plus, 
il ne faut pas confondre la licence de l'APIE avec celle du ministère de 
la justice (bravo l'APIE) voir :

http://www.regardscitoyens.org/licences-opendata-lapie-grille-la-priorite-a-etalab-et-invente-le-pseudo-libre/

Tout cela est bien dommage car il semble que DRC soit de très bonne volonté.

Désolé pour un 1er message sur cette liste d'apporter des mauvaises 
nouvelles.


Brice
@bjperson




Mais l'interprétation du texte de la licence peut être sujette à 
plusieurs

manière de la lire (elle est pas clair pour moi en tout cas)

L'article wikipedia indique que c'est une licence libre, mais aucune 
citation
(à part un article de presse dont l'auteur me semble avoir confondue 
licence
du texte de la licence et licence elle même), ce que je me suis 
permis de

compléter/corriger/mettre en doute sur WP

Sur le wiki Openstreetmap VDB semble avoir conclu que c'était bon :
http://wiki.openstreetmap.org/wiki/WikiProject_France/G%C3%A9oLittoral

"Mais la licence IP oblige une étape d'enrichissement des données 
pour pouvoir
relicencier le travail dérivé sous une autre licence (et en 
l'occurrence,
c'est ce travail qui nous permet de faire le passage IP -> CC BY-SA / 
ODbL à

terme)"

Sauf que si je lis la licence :
http://www.rip.justice.fr/information_publique_librement_reutilisable
"La présente licence précise les conditions juridiques de 
réutilisation des
informations publiques conformément à l’article 12 de la loi n°78-753 
du 17
juillet 1978 qui impose que les données  ne soient pas altérées, que 
leur
sens ne soit pas dénaturé et que leurs sources et leur date de mise à 
jour

soient mentionnées."

J'en arrive pas tout à fait à la même interprétation que lui.

Mais cette IP ressemble un peu à celle du cadastre, c'est à dire qu'elle
semble avoir pour but d'éviter que quelqu'un prenne, modifie et 
prétende que

les nouvelles données sont la responsabilité de l'organisme qui les a
libérées.
Genre : "modifier si vous voulez, mais dites bien que c'est une version
dérivée de chez nous, pas la notre"

Mais ça mériterait quand même un bon éclaircissement, de ce que je 
lis, dans

une posture de prudence, c'est non, on peut pas



Sur la page de téléchargement je lis :
"Les données peuvent faire l’objet de traitements, notamment 
lorsqu’ils sont nécessaires à la réalisation d’une nouvelle 
application ou d’un nouveau produit ou service.
On entend notamment par traitement, le regroupement d’informations, le 
renseignement de métadonnées, l‘enrichissement, les modifications 
nécessaires pour permettre l’interopérabilité des données avec 
d’autres données."


Ça ouvre quand même l'usage, en permettant d'envisager dès le départ 
que la donnée va être modifiée, par les "traitements". Modification et 
altération sont deux choses bien distinctes, la première n'implique 
pas qu'on va dégrader la source.


Concrètement si on envisage une intégration dans OSM, en rapprochant 
les tracés fournis des tracés highway=* existant dans notre base, que 
va-t-on faire ?
- découper ou agréger l'information pour la faire correspondre à la 
granularité des données OSM,
- déplacer l'information pour l'associer à des objets +/- distants, si 
le calage ou la précision géométrique de la source sont moindres que 
les tracés OSM correspondants.
Rien que par ces deux exemples, on rentre dans le cadre prévu par la 
licence : on regroupe, on enrichit (en combinant les infos à celles 
des highway=* par ex.), on modifie (au moins la géométrie), pour 
autant on ne dénature ni n'altère les données, et au final on les rend 
interopérables avec le reste des données OSM.


...mais je ne suis pas juriste.

vincent (qui voit le verre à moitié plein)

___
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] Conférence OSM le 10 avril à Orléans

[Emilie Laffray]

Salut

Je verrai si je peux venir. J'ai des gilets supplémentaires à apporter.

Émilie laffray
On 30 Mar 2013 10:26, "Etienne Trimaille" 
wrote:

> Une présentation d'OSM aura lieu le mercredi 10 avril de 20h30 à 23h00 à
> la Maison des Associations.
>
> http://www.openstreetmap.org/?mlat=47.90166&mlon=1.905425&zoom=18&layers=M
>
> http://wiki.cenabumix.org/images/ConfOSM800.jpg
>
> ___
> 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] Piste VTT (les 2 Alpes)

[Eric SIBERT]

Je tombe par hasard sur des pistes VTT aux 2 Alpes, comme par ex :
http://www.openstreetmap.org/browse/way/67502440

A l'époque, j'aurais plutôt mis un highway=track avec une relation de
type route=mtb.


Vue la faible largeur de la piste, track ne me paraît pas adapté (on ne 
peut passer en 4x4).



Alors, correct? Pas correct?


Moi, ça me va tout à fait. Il y a peut-être une légère redondance entre 
mtb:type = downhill

et
oneway = yes

Le seul qui ne va pas, c'est de couper comme ça les virages ;-)


Éric

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

[OSM-talk-fr] export d'extraits

[JB]

 

En décembre, on parlait d'exports d'extraits de la base, à la
manière de géofabrik, mais avec la possibilité de définir sa zone
(http://www.mail-archive.com/talk-fr@openstreetmap.org/msg51934.html).
Certains avaient l'air bien partants. 

Cette idée a-t-elle été
abandonnée en route, ou s'est-elle simplement endormie en chemin ? Je
lorgnais avec impatience sur cette possibilité de faire des extracts de
taille moyenne… 

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

Re: [OSM-talk-fr] Smartphone low cost à conseiller pour cartographier ?

[Christian Quest]

Disons que pour 150 à 200€ ces smartphones premier prix sont tout à fait
corrects pour faire des relevés sur le terrain et que je les conseillerai
sans problème à quelqu'un qui veut s'équiper pour mapper.

Ensuite, en fonction des autres usages qu'on peut en faire, on peut
préférer tel ou tel modèle, mais même le tout premier prix de la gamme est
suffisant.
Côté autonomie, ça n'a pas l'air trop mauvais, je suis en train de faire
encore quelques cycles de charge/décharge pour condition au mieux la
batterie, mais sur mon premier essai, j'ai tenu plusieurs heures avec le
GPS allumé. Je le testerai plus à fond à Brocas le week-end prochain et au
pire j'ai ma batterie complémentaire.


Le 30 mars 2013 12:09, Lapinos03  a écrit :

> Pour 30€ de plus, le Wiko Cink Peax, dernier né de la gamme, en offre plus
> :
> - écran plus grand (4"5)
> - résolution plus fine (qHD)
> - double de RAM : 1Go (un gros plus pour Android 4.0 et supérieur)
> - batterie un peu plus grande
> - un peu plus léger
>
> Pourquoi s'en priver à ce prix-là ?
>
> @+
>
>
> Le 30/03/13 10:39, Christian Quest a écrit :
>
>  J'ai acheté un Wiko Cink Slim* pour tester (et aussi pour essayer les
>> applis Android pour OSM).
>>
>>
>>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] export d'extraits

[sly (sylvain letuffe)]

Le samedi 30 mars 2013 15:37:41, JB a écrit :
> En décembre, on parlait d'exports d'extraits de la base, à la
> manière de géofabrik, mais avec la possibilité de définir sa zone
> (http://www.mail-archive.com/talk-fr@openstreetmap.org/msg51934.html).
> Certains avaient l'air bien partants.

Ce lien vers un de mes messages faisait référence à osm2gis qui est 
opérationnel ici :
http://www.osm974.re/osm2gis/

Sauf erreur, il utilise désormais bien la base osm2pgsql monde des serveurs de 
l'association osm-f

Arnaud, son auteur, pourra sûrement en dire plus.

-- 
sly (sylvain letuffe)

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

Re: [OSM-talk-fr] Abus des landuse=residential ?

[Guillaume Allegre]

Le sam. 30 mars 2013 à 07:52 +0100, nono a écrit :

> J'ai regardé. 
> En discutant avec des randonneurs le week-end dernier, il peut être
> intéressant de représenter les limites de parcelles « en campagne ».
> Notamment pour les lignes d'arbres, les haies, les ruisseaux, tout ce
> qui visuellement peut renseigner le randonneur sur le terrain. Ainsi, il
> se repère mieux dans l'environnement où il se trouve.

Tout à fait, mais dans ce cas, il ne s'agit pas de tracer une limite de 
parcelle,
mais un autre élément, naturel ou artificiel (barrier=hedge, 
waterway=stream|ditch...)
qui peut éventuellement marquer une limite de parcelle.



-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

[OSM-talk-fr] expérimentations à Orange

[Guillaume Allegre]

Salut, 

Je voudrais signaler certains problèmes (du moins qui m'apparaissent tels) des 
expérimentations
d'import dans OSM de données communales à Orange. Je sais que cela concerne le 
travail
de Tony, tel qu'il l'a présenté au SOTM-FR, mais je pense qu'il vaut mieux 
avoir plusieurs avis.

Prenez l'objet boundary=polling_station 
http://www.openstreetmap.org/browse/way/197278529 
membre de la relation  http://www.openstreetmap.org/browse/relation/2649371


Je vois plusieurs problèmes :

1) la boundary est une frontière de canton, qui coïncide avec un bout de la 
frontière communale
(Orange / Caderousse)
http://www.openstreetmap.org/?way=171243851 mais qui n'est pas confondue 
(points distincts)
Selon moi, elle devrait être confondue, en tant que limite communale ET limite 
de canton.

2) le way polling_station a une résolution bien plus élevée (1 point par mètre 
dans les courbes),
suivant les _anciens_ méandres de la Meyne, qui restent la limite communale 
comme ici :
http://www.openstreetmap.org/?lat=44.08722&lon=4.7789&zoom=17&layers=M
A mon avis, c'est de la sur-résolution inutile,  mais ça se discute.
Cela n'enlève rien au point 1 : il faut choisir quelle limite on prend 
(171243851 ou 197278529),
voire un intermédiaire en simplifiant la limite polling_station, mais il faut 
quand même à terme
fusionner les deux.

3) La relation 2649371 a des attributs bizarres : 
- pas de nom 
- un "CANTON=Ouest" pas documenté
- un "ref=22" pas documenté non plus

4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs :
highway = road
addr:postcode = |84100
ref:orange = 84087V99
En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un 
code postal
sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais 
tendance à le suivre
sur ce point.

Ensuite : ref:orange : là, je pense qu'on a un problème à régler. "orange" 
n'est pas suffisamment
distinctif. Si toutes les communes du monde se mettent à utiliser le même 
schéma, on va multiplier
les conflits. Comment régler ça ? 


Je ne remets pas en cause l'utilisation d'OSM comme support de données métiers 
issues 
de SIG territoriaux, bien au contraire. 
Mais si, comme je le suppose, Orange tend à devenir une zone d'exemple et de 
démonstration 
pour cette convergence, il serait préférable que le schéma suivi soit aussi 
irréprochable que possible quant à l'intégration dans les conventions standard 
OSM.
Alors, je pense qu'il faut sérieusement se pencher sur :
- le schéma d'attributs et de références qui conviendrait à tout le monde
- les conventions de fusion ou juxtaposition de données, et les précisions 
géométriques 
  minimales/maximales acceptables.

Des avis ?


-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] expérimentations à Orange

[Vincent de Chateau-Thierry]

Bonsoir,

Le 30/03/2013 20:37, Guillaume Allegre a écrit :


1) la boundary est une frontière de canton, qui coïncide avec un bout de la 
frontière communale
(Orange / Caderousse)
http://www.openstreetmap.org/?way=171243851 mais qui n'est pas confondue 
(points distincts)
Selon moi, elle devrait être confondue, en tant que limite communale ET limite 
de canton.



oui, fusionner la portion commune


3) La relation 2649371 a des attributs bizarres :
- pas de nom
- un "CANTON=Ouest" pas documenté
- un "ref=22" pas documenté non plus



S'agissant de l'extension géographique d'un bureau de vote, on peut 
concevoir qu'il n'ait pas de nom mais juste un n° (le tag ref).



4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs :
 highway = road
 addr:postcode = |84100
 ref:orange = 84087V99
En dehors de la typo sur le code postal avec le |, est-ce logique de mettre un 
code postal
sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais 
tendance à le suivre
sur ce point.



Pas sûr que ce soit une typo, ça peut être la moitié d'une modélisation 
sur un seul champ (dans un SIG) :

code_postal à gauche | code postal à droite
Pas forcément heureux là où nous sommes plus habitués à des suffixes 
:left et :right, et donc à deux attributs au lieu d'un.
Mais la modélisation directement sur les ways est banale, quasi 
conventionnelle, chez les fournisseurs de BD de géocodage (IGN, TomTom & 
co). Elle n'est pas documentée dans OSM, soit. Ça ne la rend pas 
invalide pour autant, et rien qu'en France, dans les quelques communes a 
CP multiples, ça se conçoit.



Ensuite : ref:orange : là, je pense qu'on a un problème à régler. "orange" 
n'est pas suffisamment
distinctif. Si toutes les communes du monde se mettent à utiliser le même 
schéma, on va multiplier
les conflits. Comment régler ça ?



Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut rêver), 
je verrais plutôt un schéma générique sur 2 tags :


source=* (rien de nouveau ici)
ref:source=* ou source:internal_id ou toute autre formulation pour dire 
la même chose : mentionner l'identifiant unique utilisé par le fournisseur.


Dans l'exemple du way :
source="Mairie d'Orange 2012"
ref:source=84087V99

Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un 
chacun pourrait trouver sur le terrain, mais d'un tag ref qui n'existe 
que parce qu'une certaine source a été utilisée pour l'objet.


vincent

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

Re: [OSM-talk-fr] expérimentations à Orange

[Philippe Verdy]

Le 30 mars 2013 20:37, Guillaume Allegre  a écrit :
> 3) La relation 2649371 a des attributs bizarres :
> - pas de nom
> - un "CANTON=Ouest" pas documenté
> - un "ref=22" pas documenté non plus

En effet, on a un schéma déja existant et homogène utilisant le code
Insee complet du canton à 4 chiffres dans "ref:INSEE=*". avec
"boundary=political", "political_division=canton",
"name=Orange-Ouest", "wikipedia="fr:Canton d'Orange-Ouest"


> 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs 
> :
> highway = road
> addr:postcode = |84100
> ref:orange = 84087V99
> En dehors de la typo sur le code postal avec le |, est-ce logique de mettre 
> un code postal
> sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais 
> tendance à le suivre
> sur ce point.
>
> Ensuite : ref:orange : là, je pense qu'on a un problème à régler. "orange" 
> n'est pas suffisamment
> distinctif. Si toutes les communes du monde se mettent à utiliser le même 
> schéma, on va multiplier
> les conflits. Comment régler ça ?

Pour les références relatives à Orange, ou semble-t-il plutôt son
EPCI, il serait plus utile d'indiquer "ref:FR:=*" (avec une
abréviation de l'EPCI) ou "ref:FR:=*" (si
cela vient de la commune elle-même).

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

Re: [OSM-talk-fr] expérimentations à Orange

[Guillaume Allegre]

Le sam. 30 mars 2013 à 21:58 +0100, Philippe Verdy a écrit :
> Le 30 mars 2013 20:37, Guillaume Allegre  a écrit :
> > 3) La relation 2649371 a des attributs bizarres :
> > - pas de nom
> > - un "CANTON=Ouest" pas documenté
> > - un "ref=22" pas documenté non plus
> 
> En effet, on a un schéma déja existant et homogène utilisant le code
> Insee complet du canton à 4 chiffres dans "ref:INSEE=*". avec
> "boundary=political", "political_division=canton",
> "name=Orange-Ouest", "wikipedia="fr:Canton d'Orange-Ouest"

Je reconnais que mon exemple était ambigu, mais la relation n'est pas un canton,
mais la limite d'un bureau de vote (numéro 22), qui appartient au Canton Ouest.

La question subsidiaire : vaut-il mieux avoir un nom 
"Limite du bureau de vote n°22" (complètement redondant) ou rien ?


> 4) la route http://www.openstreetmap.org/browse/way/195747326 a les attributs 
> :
> > highway = road
> > addr:postcode = |84100
> > ref:orange = 84087V99
> > En dehors de la typo sur le code postal avec le |, est-ce logique de mettre 
> > un code postal
> > sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais 
> > tendance à le suivre
> > sur ce point.
> >
> > Ensuite : ref:orange : là, je pense qu'on a un problème à régler. "orange" 
> > n'est pas suffisamment
> > distinctif. Si toutes les communes du monde se mettent à utiliser le même 
> > schéma, on va multiplier
> > les conflits. Comment régler ça ?
> 
> Pour les références relatives à Orange, ou semble-t-il plutôt son
> EPCI, il serait plus utile d'indiquer "ref:FR:=*" (avec une
> abréviation de l'EPCI) ou "ref:FR:=*" (si
> cela vient de la commune elle-même).

Non, c'est bien la commune seule. Orange ne fait à ma connaissance toujours 
partie
d'aucune intercommunalité, principalement en raison du bord politique du maire 
(ex-FN)
depuis 1995.

Le ref:FR:= * paraît rationnel, mais un peu aride.
Cela dit, pour un ref, ça peut passer.



-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] expérimentations à Orange

[Guillaume Allegre]

Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit :

> >4) la route http://www.openstreetmap.org/browse/way/195747326 a les 
> >attributs :
> > highway = road
> > addr:postcode = |84100
> > ref:orange = 84087V99
> >En dehors de la typo sur le code postal avec le |, est-ce logique de mettre 
> >un code postal
> >sur une voie ? le wiki ne donne qu'un noeud ou une surface, et j'aurais 
> >tendance à le suivre
> >sur ce point.
> >
> 
> Pas sûr que ce soit une typo, ça peut être la moitié d'une
> modélisation sur un seul champ (dans un SIG) :
> code_postal à gauche | code postal à droite
> Pas forcément heureux là où nous sommes plus habitués à des suffixes
> :left et :right, et donc à deux attributs au lieu d'un.

OK, merci, je n'y avais pas pensé.
C'est vrai que le bout de route traverse la frontière Caderousse/Orange,
qui est aussi une limite de code postal (84860/84100)  mais elle ne la suit pas.
Donc je ne sais pas si ton interprétation est la bonne.


> Mais la modélisation directement sur les ways est banale, quasi
> conventionnelle, chez les fournisseurs de BD de géocodage (IGN,
> TomTom & co). Elle n'est pas documentée dans OSM, soit. Ça ne la
> rend pas invalide pour autant, et rien qu'en France, dans les
> quelques communes a CP multiples, ça se conçoit.

OK ; ça fait sens. Mais dans ce cas, il faudrait que ce soit renseigné sur le 
wiki,
avec les variantes :left et :right.



> >Ensuite : ref:orange : là, je pense qu'on a un problème à régler. "orange" 
> >n'est pas suffisamment
> >distinctif. Si toutes les communes du monde se mettent à utiliser le même 
> >schéma, on va multiplier
> >les conflits. Comment régler ça ?
> >
> 
> Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut
> rêver), je verrais plutôt un schéma générique sur 2 tags :
> 
> source=* (rien de nouveau ici)
> ref:source=* ou source:internal_id ou toute autre formulation pour
> dire la même chose : mentionner l'identifiant unique utilisé par le
> fournisseur.
> 
> Dans l'exemple du way :
> source="Mairie d'Orange 2012"
> ref:source=84087V99
> 
> Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un
> chacun pourrait trouver sur le terrain, mais d'un tag ref qui
> n'existe que parce qu'une certaine source a été utilisée pour
> l'objet.

Oui, mais cette façon de faire limite les possibilités d'édition ultérieures :
- un objet pourrait avoir plusieurs ref (par exemple un ref:insee et un 
ref:FR:)
- un objet peut avoir plusieurs sources : un SIG territorial à l'origine, puis 
une retouche par Bing
ou par le cadastre
et le source=Mairie d'Orange irait mieux sur le changeset
Du coup, ref:source me semble trop fragile.
Je pense que ref:FR: comme proposé par Philippe Verdy est 
le plus sûr.


-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


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

Re: [OSM-talk-fr] expérimentations à Orange

[Vincent de Chateau-Thierry]

Le 30/03/2013 22:35, Guillaume Allegre a écrit :

Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit :


Ensuite : ref:orange : là, je pense qu'on a un problème à régler. "orange" 
n'est pas suffisamment
distinctif. Si toutes les communes du monde se mettent à utiliser le même 
schéma, on va multiplier
les conflits. Comment régler ça ?



Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut
rêver), je verrais plutôt un schéma générique sur 2 tags :

source=* (rien de nouveau ici)
ref:source=* ou source:internal_id ou toute autre formulation pour
dire la même chose : mentionner l'identifiant unique utilisé par le
fournisseur.

Dans l'exemple du way :
source="Mairie d'Orange 2012"
ref:source=84087V99

Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un
chacun pourrait trouver sur le terrain, mais d'un tag ref qui
n'existe que parce qu'une certaine source a été utilisée pour
l'objet.


Oui, mais cette façon de faire limite les possibilités d'édition ultérieures :
- un objet pourrait avoir plusieurs ref (par exemple un ref:insee et un 
ref:FR:)
- un objet peut avoir plusieurs sources : un SIG territorial à l'origine, puis 
une retouche par Bing
ou par le cadastre
et le source=Mairie d'Orange irait mieux sur le changeset
Du coup, ref:source me semble trop fragile.
Je pense que ref:FR: comme proposé par Philippe Verdy est 
le plus sûr.



Avec le schéma ref:FR: on pourrait se retrouver avec 
autant de clés que de communes, toutes signifiant grosso-modo la même 
chose : "cette clé a pour valeur une référence interne à la commune 
XXX". À l'extrême, 36.000 communes, 36.000 clés ? Je sais bien qu'on 
n'en arrivera pas là, je pousse juste la logique au bout. Et côté 
modélisation, autant de clés distinctes qui disent toutes la même chose, 
je trouve que ça fait beaucoup. Et dans ce scenario catastrophe, imagine 
le schéma de réutilisation, dans un modèle mis à plat comme le schéma 
standard d'osm2pgsql : 36.000 colonnes rien que pour la source...


Et c'est aussi, à sa manière, fragile. Quid de plusieurs sources issues 
de la même ville (on a facilement le cas sur les grandes villes) : la 
source des espaces verts, celle de la voirie, etc. Pour peu que les 
plages de valeurs se recoupent, le tag ref:FR: n'a plus de 
valeurs uniques dans la même ville, le bénéfice de tracer la source est 
perdu.


Ma proposition sur 2 tags a pour objectif, au moins, d'éviter la 
multiplicité des clés signifiant toutes la même chose. Je suis d'accord 
sur le fait que ça ne gère pas le multi-sources. Mais en même temps, 
est-ce que sur ces objets on n'est pas, quasi par principe, face à du 
mono-source ? Des objets issus d'un SIG communal, tracés comme tels, 
sont potentiellement maintenus côté OSM grâce au lien avec la base 
source, justement. Et si besoin, rien n'empêche d'aller un cran plus fin 
dans le détail, en sourçant chaque clé plutôt que l'objet dans sa 
globalité. On a déjà des paquets de source:addr:postcode et des 
source:ref:INSEE, sur le même principe.


vincent

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

Re: [OSM-talk-fr] expérimentations à Orange

[Christian Quest]

Si on se reposait les questions de base ?

A quoi servent ces ref:xxx ?

Si il s'agit de maintenir un lien avec un jeu de données externes bien
précis et d'une façon unique, il faut que la clé permettent d'identifier le
jeu de données sans ambiguité et donc il faut qu'elle soit unique pour
chaque jeu de données et un quelque chose du genre ref:insee:x me
semble adapté.
Ca donne en plus un lien vers le producteur de ce jeu de données x
pouvant décrire une région, un département, un EPCI, une commune, voire
même une entreprise par son SIREN/SIRET.

Si par contre ces références ont un caractère plus global et qu'elles sont
utilisables sans être liées à un jeu de données particulier, alors là il
faut utiliser une clé qui elle aussi ne soit pas liée à un jeu de données.
Si on veut identifier une référence qui serait par exemple donnée de façon
homogène par un niveau administratif particulier, on pourrait envisager un
ref:admin_level:xx=*

Vous allez voir qu'on va y arriver aux linked data ;)

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

Re: [OSM-talk-fr] expérimentations à Orange

[Philippe Verdy]

Le 30 mars 2013 22:26, Guillaume Allegre  a écrit :
> Le sam. 30 mars 2013 à 21:58 +0100, Philippe Verdy a écrit :
>> Le 30 mars 2013 20:37, Guillaume Allegre  a écrit 
>> :
>> > 3) La relation 2649371 a des attributs bizarres :
>> > - pas de nom
>> > - un "CANTON=Ouest" pas documenté
>> > - un "ref=22" pas documenté non plus
>>
>> En effet, on a un schéma déja existant et homogène utilisant le code
>> Insee complet du canton à 4 chiffres dans "ref:INSEE=*". avec
>> "boundary=political", "political_division=canton",
>> "name=Orange-Ouest", "wikipedia="fr:Canton d'Orange-Ouest"
>
> Je reconnais que mon exemple était ambigu, mais la relation n'est pas un 
> canton,
> mais la limite d'un bureau de vote (numéro 22), qui appartient au Canton 
> Ouest.

Oui mais le nom donné semble indique que le bureau 22 correspond en
fait à la même chose que la fraction du canton sur le territoire de la
commune. Hors un bureau de vote est très souvent beaucoup plus petit
qu'un canton ou même qu'une fraction cantonale. Donc le nom donné
"Canton Ouest" était bien ambigu. Et devait bien indiquer "bureau de
vote n° 22" même s'il appartient à la fraction du canton
d'Orange-Ouest sur le territoire de la commune d'Orange.

A l'heure actuelle, il n'y a pas de schéma défini pour les bureaux de
vote, mais si un schém s'impose cela devrait rester une subdivision du
canton dans un autre type de subdivision pour boundary=political. [Il
me semble qu'au Royaume-Uni il y a des définitions pour les "polling"
areas.]

> La question subsidiaire : vaut-il mieux avoir un nom
> "Limite du bureau de vote n°22" (complètement redondant) ou rien ?

Pas redondant, mais en tout cas ne pas faire de confusion avec les
limites de cantons, et tant que la carte des bureaux de vote de la
commune ou du canton n'est pas complètement établie, il est prématuré
de vouloir faire une conflation des limites de ces bureaux de vote
avec les frontières de communes ou de cantons.

[
Il me semble qu'aucun bureau de vote, pour les élections au suffrage
universel, ne peut couvrir des territoires de communes différentes ni
de cantons différents, ni de circonscriptions législatives
différentes, ni de circonscriptions régionales ou européennes
différentes, car ce sont les communes qui ont la charge de les
organiser (à défaut de moyens, c'est le préfet du département qui
fournit les moyens dans la commune pour ses électeurs) ; la question
ne se pose pas pour les circonscriptions sénatoriales puisque pour les
sénatoriales les votes ne sont pas organisés par les communes mais par
les départements, pour les électeurs élus territoriaux, ou par les
régions pour les électeurs élus régionaux, par le biais su suffrage
indirect qui fonctionne très différemment et n'est pas lié directement
aux territoire de vie des citoyens électeurs
Mais ces bureaux de vote ne sont pas des subdisivions administratives,
et devraient rester dans des "boundary=political" avec un type
différent pour "political_subdivision".
].

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

Re: [OSM-talk-fr] export d'extraits

[arnaud....@gmail.com]

Hola,

JB, quelle serait l'étendue de la zone que tu souhaiterais exporter.
En terme de développement, je suis un peu pris en ce moment.
Néanmoins, je planifie d'apporter des modifications à osm2gis d'ici un 
mois ou deux.


Donc c'est le moment de remplir le cahier de doléances :)

Arnaud

On 30/03/2013 14:01, sly (sylvain letuffe) wrote:

Le samedi 30 mars 2013 15:37:41, JB a écrit :

En décembre, on parlait d'exports d'extraits de la base, à la
manière de géofabrik, mais avec la possibilité de définir sa zone
(http://www.mail-archive.com/talk-fr@openstreetmap.org/msg51934.html).
Certains avaient l'air bien partants.

Ce lien vers un de mes messages faisait référence à osm2gis qui est
opérationnel ici :
http://www.osm974.re/osm2gis/

Sauf erreur, il utilise désormais bien la base osm2pgsql monde des serveurs de
l'association osm-f

Arnaud, son auteur, pourra sûrement en dire plus.




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

Re: [OSM-talk-fr] Abus des landuse=residential ?

[arnaud....@gmail.com]

Vincent,

Je comprends mieux maintenant la différence.
D'autant plus si, comme le souligne Jean-François nous ne sommes pas 
autorisé à le faire.

Néanmoins, fusionner l'ensemble des données c'est un peu violent non?
Nous pourrions commencer à entamer une discussion avec le contributeur 
afin de lui expliquer notre démarche.



Arnaud


On 29/03/2013 17:47, Vincent Pottier wrote:

Le 29/03/2013 18:56, arnaud@gmail.com a écrit :

Vincent,

J'ai du mal à comprendre en quoi est-ce un abus?
Je comprends ta position, mais ce n'est pas pire que d'ajouter le 
numéro de boite aux lettres non?


A.

Bonne question...
Je le sens et j'essaie de comprendre.
Je réfléchis à haute voix...

Nous ne mettons pas le numéro de boite aux lettres mais le numéro dans 
la rue. C'est à dire une information géographique ponctuelle : le n° N 
est ici. Peu importe le nombre de boites aux lettres : une seule 
probablement pour un pavillon, 15-20 pour une entrée d'immeuble.
Ce numéro, qui est aussi l'adresse postale, est d'abord une adresse 
géographique, une adresse civile : le numéro tant de la rue machin de 
la commune truc. Ce n'est pas la poste qui nous a attribué le numéro, 
mais la commune.
De plus c'est un élément ponctuel. C'est à dire qu'il comporte en lui 
même peu d'information géographique sinon une latitude et une longitude.


L'information sur un champ m'intéresse. Que le champ de colza fasse 
telle surface, que le verger ait telle forme, ça m'intéresse. Mais 
qu'il soit sur une, deux ou quinze parcelles, cela ne me regarde pas 
(du point de vue OpenStreetMap).


En entrant le découpage parcellaire, on change la nature des données. 
On n'est plus seulement dans l'information géographique, présence 
limites réelles ou administratives, d'objets réels ou publics. On 
introduit des données non matérielles privées.


Certes, j'ai entré un certain nombre de numéros de téléphones 
(contact:phone) mais seulement pour des entreprises. Et le numéro de 
téléphone est une "interface publique" de ces entreprises privées. 
Comme le numéro dans la rue.


La limite de propriété est une information sur une personne privée 
(physique ou morale) qui n'est pas de l'ordre de cette "interface 
publique".


Peut-être est-ce cette notion, floue, qui me faisait écrire au feeling 
que la limite de l'espace public/privé m'intéressait. Mais pas au delà.
Derrière le numéro de téléphone, je ne dirai pas s'il y a un ou quinze 
postes. Derrière le numéro dans la rue, je ne dirai pas quelle est la 
taille de la propriété (même si le mur de clôture, information sur un 
objet réel, le suggère). Je dirai le mur, pas la parcelle.


Voila pour ce soir.
--
FrViPofm


___
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] expérimentations à Orange

[Philippe Verdy]

Le 30 mars 2013 23:14, Vincent de Chateau-Thierry  a écrit :
>
> Le 30/03/2013 22:35, Guillaume Allegre a écrit :
>>
>> Le sam. 30 mars 2013 à 21:45 +0100, Vincent de Chateau-Thierry a écrit :
>>
 Ensuite : ref:orange : là, je pense qu'on a un problème à régler.
 "orange" n'est pas suffisamment
 distinctif. Si toutes les communes du monde se mettent à utiliser le
 même schéma, on va multiplier
 les conflits. Comment régler ça ?

>>>
>>> Pour éviter d'avoir 36.000 tags ref:* distincts à terme (on peut
>>> rêver), je verrais plutôt un schéma générique sur 2 tags :
>>>
>>> source=* (rien de nouveau ici)
>>> ref:source=* ou source:internal_id ou toute autre formulation pour
>>> dire la même chose : mentionner l'identifiant unique utilisé par le
>>> fournisseur.
>>>
>>> Dans l'exemple du way :
>>> source="Mairie d'Orange 2012"
>>> ref:source=84087V99
>>>
>>> Après tout, il ne s'agit pas d'un tag ref pour l'objet, que tout un
>>> chacun pourrait trouver sur le terrain, mais d'un tag ref qui
>>> n'existe que parce qu'une certaine source a été utilisée pour
>>> l'objet.
>>
>>
>> Oui, mais cette façon de faire limite les possibilités d'édition
>> ultérieures :
>> - un objet pourrait avoir plusieurs ref (par exemple un ref:insee et un
>> ref:FR:)
>> - un objet peut avoir plusieurs sources : un SIG territorial à l'origine,
>> puis une retouche par Bing
>> ou par le cadastre
>> et le source=Mairie d'Orange irait mieux sur le changeset
>> Du coup, ref:source me semble trop fragile.
>> Je pense que ref:FR: comme proposé par Philippe Verdy
>> est le plus sûr.
>>
>
> Avec le schéma ref:FR: on pourrait se retrouver avec
> autant de clés que de communes, toutes signifiant grosso-modo la même chose
> : "cette clé a pour valeur une référence interne à la commune XXX". À
> l'extrême, 36.000 communes, 36.000 clés ? Je sais bien qu'on n'en arrivera
> pas là, je pousse juste la logique au bout. Et côté modélisation, autant de
> clés distinctes qui disent toutes la même chose, je trouve que ça fait
> beaucoup. Et dans ce scenario catastrophe, imagine le schéma de
> réutilisation, dans un modèle mis à plat comme le schéma standard
> d'osm2pgsql : 36.000 colonnes rien que pour la source...

Là tu pousses à l'extrême car ces clés ne sont pas destinées à devenir
des "features" au sens OpenGIS, mais des métadonnées à distinguer
parmi celles pouvant renseigner un objet GIS.

Hors on se retrouvera vite avec des clés fournies ou référencées par
deux collectivités différentes, par exemples sur les voiries partagées
par deux communes (ou plus). Si chacun a sa propre référence dans son
SIG, on fait comment ? Même si une seule des sources a été utilisée
(les autres sont d'accord sur le tracé, il n'y a pas d'ambiguité que
c'est bien le même objet référenc, chaque source devrait pouvoir faire
le lien avec son propre système de référence, car il n'y a pas
garantie que les références utilisées par un SIG soient les mêmes que
celle du SIG voisin (à moins qu'il y ait une convention commune
adoptée entre les collectivités pour qu'elles utilisent la même
référence interne pour faciliter les échanges entre les
collectivités).

Si ces collectivitées sont deux communes d'une même EPCI, elles se
mettront d'accord avec le SIG de l'EPCI qui fera la lien. Mais il
restera tout de même encore des liaisons à faire entre les SIG de deux
EPCI différents, ou d'un EPCI et d'une commune hors EPCI. Ces communes
peuent être aussi dans un autre département ou une autre région.

Quand je proposais "ref:FR: = *", il était évident qu'on
pouvait y mettre toute référence insee : un département à deux
chiffres/lettres, une commune à 5 chiffres, mais si nécessaire on doit
pouvoir être plus précis et indiquer le type de collectivité :
- "ref:FR:région: = *"
- "ref:FR:département: = *"
- "ref:FR:commune: = *"
- "ref:FR:EPCI: = *"

Si au sein de la même collectivité il peut y avoir plusieurs sources
utilisant des numéros de référence différents (service des espaces
verts d'une commune par exemple), on peut sous-qualifier:
- "ref:FR:EPCI::esp-verts = *"

Note: les références nationales pour désigner les territoires entiers
des collectivités elles-mêmes (ou autres subdivisions administratives
voire aussi les cantons) restent:
- "ref:INSEE = "

Les académies pourraient avoir leurs propre références pour les
établissements qu'elles gèrent:
- "ref:FR:académie:=*"

Chacun a sa clé de référence pour faire la liaison avec son SIG.

Idem pour les régions militaires (mais là je pense qu'on n'a pas accès
aux références internes, et que c'est géré en fait par le ministère de
la défense, y compris pour les gendarmeries)

> Ma proposition sur 2 tags a pour objectif, au moins, d'éviter la
> multiplicité des clés signifiant toutes la même chose.

Cela ne multiplie pas les clés. Les "ref:*" ne sont pas des "features"
au sens GIS se ne sont que des métadonnées attachées en complément à
un autre feature.

Et les ref indiquées ne sont pas non plus nécessairement les sou