Re: [OSM-talk-fr] osmose

[Philippe Verdy]

C'est pas mal comme idée, pour mettre des références destinées au
routage multimodal: les entrées associées pourraient ne pas être
limitées qu'aux piétons sur les trottoirs, mais inclure les
interconnexions diverses avec les lignes ferrovières en incluant le
point sur la ligne de métro elle-même et pas seulement ses entrées.

Est-ce que ça peut se généraliser à tous les transports multimodaux
(car, bus, métro, tram, train, taxi, aéroport, vélo, piéton, tapis
roulants, ascenseurs, fauteuils roulants...) ? Avec une estimation du
temps de parcours entre tous les accès selon le moyen utilisé pour
passer de l'un à l'autre, par exemple pour une correspondance entre
lignes de transport ?

Le 8 mars 2012 09:21, adrien carpentier  a écrit :
> oui, bien sur sur paris, voilà un lien osmose ci-dessous
> presque toutes les stations de métro, on dirait une relation entre les
> entrées de la même station
> mais je ne trouve rien de proposé de tel du coup, osmose les range en tag
> incorrect...
>
> http://osmose.openstreetmap.fr/map/?zoom=14&lat=48.86832&lon=2.37543&layers=B0FF00T&item=3040
>
> exemple : 
>   
>   
>   
>   
>   
>   
>   
> 
>
> adrien
>
> Le 7 mars 2012 23:04, Jocelyn Jaubert  a écrit :
>
>> Le 7 mars 2012, adrien carpentier a écrit :
>> > merci pour vos réponses au point 1 et 3!
>> > une idée pour ça??
>> > 2: sur paris, j'ai vu beaucoup de associatedStation
>> > osmose n'aime pas et je n'ai pas trouvé ça sur le wiki
>> > idem quelle correction proposez-vous?
>>
>> Est-ce que tu peux donner un lien vers une erreur ?
>>
>> Je ne vois pas trop de quelle erreur osmose tu parles, à moins que ce
>> ne soit au sujet des associatedStreet ?
>>
>>
>> --
>> Jocelyn
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> --
> http://www.virage-energie-npdc.org/
>
> ___
> 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] Cartes ou couches informations géoréreférencées (adressage) de Paris et sa banlieue dans les années 1930

[Philippe Verdy]

Avant de mettre des données historiques dans la base OSM, vous avez
fait un test dans une petite zone limitée (et pas trop riche en
données) pour savoir cpomment allaient se comporter les fournisseurs
de cartes avec ces données ?

Il me semble qu'aujourd'hui quand un simple carrefour est modifié on
change les données et on ne garde pas les précédentes. Vous allez les
mettre où ces données historiques ? Avec quel tag pour éviter les
confusions avec les données actuelles ? A-t-on défini un schéma
standard reconnaissable pour ces données anciennes qui devront
nécessairement avoir des tags datés et ajouter une surcharge de ways
et noeuds qui ne correspondent plus à rien actuellement ?

A mon avis il vaut mieux envisager de mettre ça dans une base séparée
destinées à ces données historiques (même celles de création récente
pour les modifications bien actuelles de voiries et usages). Et cette
base serait alors vite beaucoup plus volumineuse que la base
principale à cause des nombreuses modifications récents qui
viendraient la compléter sans cesse.

Une façon de faire serait de limiter les bases historiques par
décennie (pour les plus récentes), ou par siècle (pour les plus
anciennes, d'avant 1800 environ), sur des serveurs eux aussi
distincts. Bref de créer un réseau de bases de données distinctes,
toutes n'étant pas forcément maintenenues par la Fondation OSM mais
par des tiers référençant seulement dans la base OSM l'existence de
ces bases historiques (on a bien des collections de bases pour nos
fournisseurs actuels de cartos ou d'orthophotos, il doit aussi y avoir
moyen de référencer davantage de bases construites avec les outils
d'OSM...).

Le 8 mars 2012 10:14, nicolas chavent  a écrit :
> Je recherche des couches d'information géographiques (linéaire routier/
> rues) sur Paris et sa banlieue dans les années 1930 ou des cartes de cette
> époque.

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

Re: [OSM-talk-fr] Usage d'OSM par les infographistes...

[Philippe Verdy]

D'accord, mais même si le prix du papier est à la hausse, c'est à
cause du prix de l'eau (et de son retraitement ensuite) et de
l'énergie nécessaire. Les acheteurs de la filière papier ne donnent
pas grand chose aux producteurs de bois. Ces bois pauvres continuent
d'avoir une faible valeur, et la seule façon de rentabiliser ça c'est
avec des espèces à pousse rapide, pas du tout intéressant au plan
écologique, et très mal payé, avec des aléas très forts sur les cours
d'achat pour les producteurs.

Bon nombre ont arrêté les frais, les prix offerts par les producteurs
de pâte à papier ne couvrant pas l'entretien et l'investissement, qui
n'est rentable que quand c'est de la culture quasi industrielle (qui
est très nocive pour les sols et les ressources en eau utlisées par
ces forêts artificielles, donc très réglementées). En plus les espèces
à pousse trop rapide, ont un défaut : les coupes trop fréquentes, les
arrachages de racines, fragilisent les sols, qui ne peuvent pas se
reconstituer. Le sol s'apauvrit alors au lieu de s'enrichir avec le
temps car il n'y a plus assez de place pour les déchets végétaux.

Et se développent aussi une surpopulation de certains insectes, faute
d'une faune avière suffisante qui ne s'y abrite pas. Les bois qui
poussent sont alors rongés par les termites et autres nuisibles (car
en surpopulation faute de prédateurs suffidants) qui viennent ensuite
contaminer nos villes. La forêt des Landes est maintenant un foyer
permanent des termites en France, c'est quasi irréversible (il
faudrait traiter, mais la poluation serait pire que le remède et
personne ne veut payer ces traitements, surtout pas les producteurs de
pâte à papier) et ça menace les forêts anciennes d'espèces plus
précieuses.

De fait, les contraintes étant trop fortes pour les producteurs, ils
n'entretiennent plus non plus leurs parcelles, le risque d'incendie se
développe aussi sur les sous-étages qui sont surtout colonisées par
trop peu d'espèces végétales à pousse elle aussi rapide (trop de
fougères, pas assez de ronces, pas assez de champignons) qui n'offrent
pas d'abris intéressants non plus pour la faune. Si on les pousse à
faire quelquechose, ils se contentent de ramasser le bois mort tombé à
terre, ou attendent que d'autres viennent le prendre. Une fosi les
arbres tous à terre, ils ne s'occupent pas de la repousse, donc ne
font plus de sélection et de clairsemage. (en soit c'est pas un mal,
mais à très long terme, car alors ça donne dans ce capharnaum naissant
l'occasion de restaurer des niches, et l'apport d'espèces végétales
plus nobles par les oiseaux. Des pins repousseront, des chˆnes ou
hêtres mettront plus de temps, les pins retomberont, et peut être
qu'il y aura alors une meilleure forêt, pluriétagée, plus économe en
resources et qui reconstituera les sols (avec l'aide des champignons)
mais en attendant, ce sont des bombes à incendies (et pour que cela
redevienne une vraie forêt plus naturelle, il va falloir beaucoup de
chances ratées)...

Non pour moi cette forêt plantée des Landes est une aberration née
d'une volonté industrielle qui a perdu sa rentabilité, et fait courir
de grands risques. Des risques qui ne font qu'augmenter maintenant que
l'homme se sert trop largement des ressources en eau. Pour redevnir
une vraie forêt ce n'est pas gagné, avec le réchauffement climatique
et l'augmentation de la fréquence et la force des tempêtes qui mettent
à terre plus souvent des arbres fragiles peu résistants, et mal
implantés trop rapidement sur un sol qui ne peut pas bien les retenir.

> Il ne faut pas oublier que le papier est produit à partir du bois et les
> quantités de bois absorbées par la filière de la pâte à papier sont sans
> commune mesure avec celle des palettes ou de la construction.

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

Re: [OSM-talk-fr] Re : Apple, iOS, Google Maps... et OSM ?

[Philippe Verdy]

Le 10 mars 2012 08:21, Arnaud CORBET  a écrit :
> Je suis absolument certain que OSM a servi de base à Apple. Involontairement
> j'ai glissé un "oster egg" dans ma cartographie OSM.

OK admettons... Si Apple avait utilisé les sources ouvertes publiques,
il n'aurait pas omis des segments entiers de départementales.
Visiblement ils ont juste mis un filtre destiné à savoir si les
données OSM cadrent avec les orthophotos qu'ils ont, pour faire croire
qu'ils les ont cartographiés eux-mêmes.

Donc Apple est un tricheur.

PS: on dit « Easter egg » en anglais, ou « Osterei » en allemand.
« Easter » et « Oster » traduisent « Pâques » ; « egg » et « Ei »
traduisant « œuf ».

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

Re: [OSM-talk-fr] Guipel (FR-35)

[Philippe Verdy]

Note : il n'est pas inutile de regarder la date des orthophotos de
Bing : elles ont pu être calées à une époque où les GPS fournissaient
des décalages volontaires et un peu aléatoire dans certaines zones
"sensibles", voire sur des pays entiers. Ca peur se voir avec des
défaut d'alignements des images entre plusieurs zones. De plus Il
n'est pas impossible que ces images n'aient pas été correctement
"rectifiées" pour se caler en WGS84. Cela peut concerner une partie
seulement des images, et peut ne pas concerner de la même façon toutes
les époques de prises de vue, et ce décalage pourrait disparaître sans
prévenir, ou réapparaître de façon différente en cas de mise à jour
(si toujours aussi mal rectifiée).

Comparer aussi avec les images fournies par Google Maps/Earth (les
deux fournisseurs utilisent CNES Spot Images dont ils sont clients,
mais ces images n'ont pas toutes été fournies en WGS84, à charge pour
les fournisseurs de faire ce travail de changement de projection, mais
ils ne font pas les mises à jour en même temps ou en même quantité,
car ils doivent acheter les droits sur ces images à un instant T, pas
forcément le même pour les deux fournisseurs).

Noter quand même que les photos satellitaires correspondent à des
projections coniques dont le centre bouge sans arrêt (en coordonnées,
mais aussi un peu en altitude). Elles doivent toujours être rectifiées
vers une autre projection standard, ce qui nécessite d'avoir les
coordonnées précises du satellite au moment de sa prise de vue, ou de
pouvoir calculer cette position précise entre deux relevés de position
(grâce à une horloge suffisamment précise dans le satellite pour dater
précisément les photos).

En principe CNES Spot Images doit faire lui-même ce travail de
conversion vers une projection standard bien calibrée avant de fournir
ses photos. Il faut aussi que Microsoft ou Google ne se trompent pas
de projection proposée par CNES Spot Images quand ils lui commandent
un catalogue de photos car ces images ne sont pas toutes en WGS84, pas
très bien adaptée en terme de précision pour les latitudes non
équatoriales, car entraînant des aberrations géométriques
significatives liées à la projection cylindrique WGS84 elle-même
(alors que les images sont plus précises, moins floues, et conservent
mieux surfaces, angles et distances avec une projection NON centrée
sur le plan équatorial, mais sur la position du satellite lui-même au
moment de sa prise de vue, qui se fait si possible "pas trop loin" de
la verticale du lieu photographié !).

Certaines images anciennes ne sont pas en WGS84 car la résolution des
photos était insuffisante pour faire une rectification exploitable
visuellement pour montrer correctement des détails submétriques, ou
parce que les algos de rectification de l'époque ne savaient pas bien
faire un lissage géométriquement correct des pixels sources (dont le
carré initial devient en principe un trapézoïde dans la projection
rectifiée, avec une erreur introduite ensuite lorsque ce trapézoïde
est rééchantillonné dans la nouvelle grille orthogonale de pixels
nécessairement "arrondis", erreur qui vient s'ajouter aussi à celle de
la recompression JPEG de l'image rééchantillonnée, car JPEG indoduit
des erreurs d'échantillonnage et des aberrations géométriques
sinusoïdales et colorimétriques sur ses blocs et macroblocs selon le
niveau de compression appliqué...).

Il y a aussi des prises de vue satellitaires à 45 degrés utiles aussi
pour relever les altitudes, par comparaison avec les photographies à
la verticale, mais maintenant les données d'altitude sont plutôt
relevées à la verticale par un système radar, qui fournit des données
altimétriques plus précises, qui servent plus tard à rectifier
correctement les photos en supprimant mieux l'effet de perspective.

Le 12 mars 2012 01:26, Philippe Verdy  a écrit :
> Très probablement les repères géodésiques ont été importés avec des
> coordonnées non converties correctement en WGS84. Regarder la fiche de
> définition de ces repères géodésiques à leur source pour savoir quel
> système de coordonnées a été utilisé (il est probable que ce sont les
> coordonnées Lambert légales françaises qui ont été importées pour ces
> repères, qui sont alors à corriger).
>
> Si les repères sont bien convertis, alors c'est Bing qui n'a pas
> correctement géolocalisé ses images, et il y a un décalage visible :
> qu'il faut corriger partout autour pour réaligner les données sur les
> points géodésiques... Le mieux est tout de même de faire ce recalage
> avec un outil qui fera un réalignement des données OSM "lissé" autour
> de ces points, afin de ne pas provoquer d'aberrations géométriques
> tout autour par un décalage en masse. Pour le faire, il suffit de
> mettre d'abord dans la base un noeud correspondant à la position
> donnée par Bing, afin que ce noeud serve de référence pour recaler
> tout ce qui est autour.
>
> Et ne pas oublier de signaler l'anomalie à Bing et sur la base de
> réalignement des sources "orthophot

Re: [OSM-talk-fr] Guipel (FR-35)

[Philippe Verdy]

Très probablement les repères géodésiques ont été importés avec des
coordonnées non converties correctement en WGS84. Regarder la fiche de
définition de ces repères géodésiques à leur source pour savoir quel
système de coordonnées a été utilisé (il est probable que ce sont les
coordonnées Lambert légales françaises qui ont été importées pour ces
repères, qui sont alors à corriger).

Si les repères sont bien convertis, alors c'est Bing qui n'a pas
correctement géolocalisé ses images, et il y a un décalage visible :
qu'il faut corriger partout autour pour réaligner les données sur les
points géodésiques... Le mieux est tout de même de faire ce recalage
avec un outil qui fera un réalignement des données OSM "lissé" autour
de ces points, afin de ne pas provoquer d'aberrations géométriques
tout autour par un décalage en masse. Pour le faire, il suffit de
mettre d'abord dans la base un noeud correspondant à la position
donnée par Bing, afin que ce noeud serve de référence pour recaler
tout ce qui est autour.

Et ne pas oublier de signaler l'anomalie à Bing et sur la base de
réalignement des sources "orthophotographiques" !

Le 11 mars 2012 11:40, Pieren  a écrit :
>> - à l'Ouest du bourg de Guipel, il y a 3 repères pour un même château d'eau
>> et tous à l'extérieur du cercle le représentant issu du cadastre;
>
> L'exemple le plus intéressant. Je n'ai pas regardé l'historique des
> objets OSM mais si personne n'a déplacé les éléments depuis leur
> import, le bâti cadastral est décalé d'un mètre à l'ouest et
> l'imagerie Bing, d'un mètre à l'est. Les repères géodésiques étant LA
> référence, ce sont les autres qui sont faux (cadastre, Bing).
>
>> - dans le bourg, le repère du clocher de l'église.
>
> Là, ça colle presque parfaitement (il faut aussi tenir compte de la
> déformation entre l'emprise au sol et le toit). Bing reste en léger
> décalage mais ça reste dans le domaine de l'acceptable comme pour les
> autres exemples cités (< 5 mètres). Hey, les gars, il ne faut pas
> oublier qu'aux débuts d'OSM, il n'y avait pas d'imagerie aérienne, ni
> de cadastre. Et qu'ensuite il y a eu Yahoo et que ce genre de bled,
> c'était un gros pâté tâché avec du vert et du gris. Alors ne venez pas
> râler quand Bing et le cadastre sont en décallage d'un mètre ou deux
> ;-) Il y a plein d'endroits dans le monde où ils seraient bien
> contents d'avoir des sources de la même qualité que les nôtres.

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

Re: [OSM-talk-fr] doublon way fermé

[Philippe Verdy]

Certes, mais certains choix destinés à faciliter le travail doivent
aussi être justifiés techniquement par ce qu'on sait faire à coût
raisonnable : calculer (et recalculer) en permanence un squelette
filaire à partir d'une donnée surfacique n'est pas envisageable pour
l'instant, raison pour laquelle on a accepte de coder les deux, afin
que les moteurs de rendus puissent choisir laquelle des
représentations afficher sans trop de difficultés.

Le filaire (y compris les nœuds isolés) malgré tout a ses limites, et
le surfacique (défini par des contours et non par un tracé central)
est souvent bien meilleur en terme de précision pour des cartes à
haute résolution, alors que le filaire est mieux adapté à des
résolutions limitées qui ne permettraient normalement pas de voir le
surfacique (un tracé fialire peut avoir un rendu d'une épaisseur
arbitraire bien supérieure à ce que représente l'échelle de la carte:
sur une carte routière des autoroutes de France par exemple, les
autoroutes ou voies rapides représentées paraissent beaucoup plus
larges qu'elles ne sont en réalité à cette échelle).

Bref les deux modes de représentation en même temps sont parfaitement
justifiés, même pour les réseaux de transport routier voire aussi
ferroviaire, bien que là on a des largeurs de voies très homogènes
(ces deux modes de représentation sont compatibles entre eux, à
condition de BIEN distinguer les deux dans la façon de taguer les
éléments : c'est pour ça qu'on a des rôles étiquetés différemment dans
les relations : pour les rivières on a bien les classiques
"inner"/"outer" pour le surfacique, et "main_stream"/"side_stream"
pour le filaire central ; il est alors nécessaire de préciser les
choses et ne PAS laisser de rôles vides ambigus à interpréter).

Actuellement les routes sont principalement cartographiés en filaire,
avec une seule voie centrale "virtuelle" : c'est suffisant à condition
de ne pas vouloir créer de carte à haute résolution, et de ne pas
vouloir faire de guidage précis sur les changements de voies, ou pour
des voies à circulation restreinte ou réservées à autre chose que la
circulation automobile générale (y compris les trottoirs, pistes
cyclables, voies bus, bande d'arrêt d'urgence...).

Si on commence à vouloir détailler les voies multiples, prenant aussi
en compte leur sens de circulation, il y a lors des relations à
définir (une pour le surfacique, la relation surfacique pouvant
référencer un chemin filaire san entrer dans le détail des voies de
circulation) ; la séparation des voies ne permet plus de savoir si
elles sont en fait une même rue (avec le même nom et la même
référence) : la relation séparée de surface permet cependant
d'indiquer cela (mais il est plus pratique de grouper les voies
filaires dans une relation filaire qui fournit le nom commun, et qui
peut encore être référencée par la relation surfacique, tandis que la
relation surfacique désignera seulement la voie centrale virtuelle de
son squelette)  : le chemin central virtuel squelettique passe dans
cette surface qui lui donne son nom... Ensuite les moteurs de rendus
choisiront ce qui leur est le mieux selon la résolution à laquelle ils
travaillent.

Quand le travail sera bien avancé, on se posera nécessairement la
question de faire évoluer le modèle un peut trop filaire du routier,
qui ne permet pas des associations faciles pour des éléments (on a
déjà les relations de type "associatedStreet" pour les adresses, des
relations pour les lignes de transport des réseaux de bus, avec des
voies représentables séparément pour chaque sens dont les arrêts sont
différemment placés, et il est difficile de "recoller" ces morceaux
ensembles sans une relation de surface, par exemple pour des échanges
de transport multimodaux, si en plus on ne veut pas voir dans la carte
de "ways" partiellement ou totalement superposés, trop difficiles à
modifier là où un seul way aurait suffit en utilisant des relations
séparées...).

Le 11 mars 2012 23:03, monsieur a  a écrit :
> Et moi qui pensais que la puissance d'Osm etait sa relative facilite de
> prise en main, qu'un simple cap cuisine etait suffisant sans avoir besoin
> d'un bac +12 en géographie.
>
> Je devais me tromper. :(

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

Re: [OSM-talk-fr] doublon way fermé

[monsieur a]

Et moi qui pensais que la puissance d'Osm etait sa relative facilite de
prise en main, qu'un simple cap cuisine etait suffisant sans avoir besoin
d'un bac +12 en géographie.

Je devais me tromper. :(
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bypass sur autoroute

[Philippe Verdy]

Il me semble que les glissières de sécurité (guard_rail) sont alignées
avec le sens de l"autoroute, alors que le bypass est une voie de
service barrée par ces glissières. Ce sont dont des objets
diffférents, avec des "ways" qui se croisent (au pire on ne mettra
"guard-rail" que sur un seul nœud central du de la voie de circulation
"bypass", là où la barrière traverse ce bypass. On ne tague pas les
barrières temporaires guidant vers la traversée du bypass quand il est
ouvert, mais seulement la barrière coupant habituellement fermée
traversant ce bypass.

Le bypass est donc une voie routière comme une autre, même si elle est
habituellement fermée, et généralement elle n'est en sens unique que
temporairement, le sens de circulation dépendant de la déviation faite
au moment où le bypass est ouvert. Donc on ne le tagguera généralement
pas non plus en "oneway=yes" sauf si le bypass n'est utilisable que
dans une seule direction possible.

Donc seulement :
> highway=service
> oneway=no
> access=no
> service=bypass

Pour:
> barrier=guard_rail
c'est à poser sur le way qui traverse le bypass et qui se prolonge
tout le long de l'autoroute, sur son terre-plein.

On trouve ces bypass non seulement sur les autoroutes mais sur
n'importe quelle route à voies de circulation séparées (nationale, ou
départementale, voire même communales en ville sur des boulevards
larges) ; et même parfois entre une route principale à chaussées
séparées (hors des sections payantes d'autoroutes.

Sauf cas extrême où une section payante devrait temporairement être
rendue gratuite, ce qui nécessiterait de laisser ouvert les péages
avec passage gratuit) et une route secondaire parallèle à circulation
dans les deux sens qui peut servir à évacuer la route principale en
cas d'urgence ou peut permettre à des véhicules de secours
d'intervenir plus rapidement sans se faufiler entre les bouchons créés
par un accident.

Ou pour justement dérouter les véhicules afin qu'ils n'aillent pas
s'agglutiner sur les lieux de l'accident. Souvent cela impose une
sortie obligatoire au péage ou la sortie précédant ce lieux, et la
pose d'une signalisation lumineuse (ou de panneaux réorientables
télécommandés pour limiter la vitesse et avertir d'un rétrécissement
des voies) et de cônes de barrage vers la sortie, pour prévenir les
conducteurs qu'ils doivent quitter la route principale et prendre un
réseau secondaire. Dans de tels cas, la police ou gendarmerie est
rapidement sur les lieux pour aider les véhicules à faire demi-tour en
sécurité sur une voie restreinte s'ils ont déjà passé ce point de
sortie et si le barrage ne peut être levé rapidement, ou sinon de leur
demander d'attendre et de se garer correctement pour dégager une voie
de passage des secours.

Le 11 mars 2012 22:23, Jean-Francois Nifenecker
 a écrit :
> Le 11/03/2012 19:58, didier2020 a écrit :
>
>>
>> pour les autoroutes d'ile de france, ce n'est pas emergency_access:
>> cela sert dans le cadre des travaux important et rarement pour une
>> deviation provisoire d'accident ou autre (délais de mise en place trop
>> important : demontage + mise en place des cones de lubeck).
>>
>
> En résumé, après les remarques de Marc et Didier :
>
> highway=service
> oneway=no
> access=no
> barrier=guard_rail
> service=bypass
>
> --
> Jean-Francois Nifenecker, Bordeaux
>
>
> ___
> 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] doublon way fermé

[Philippe Verdy]

Note; je ne dis pas qu'on devrait supprimer alors le filaire des
routes, bien au contraire, comme on garde le filaire des rivières
(question de performance). Si on met le surfacique ce sera en plus du
filaire, pour permettre des cartes à haute résolution. Et pour le
faire il faudrait généraliser les relations pour les routes afin de
rassembler dans un même objet les filaires et les surfaciques (avec
des rôles distincts : inner/outer pour le surfacique, et
main_road/side-road pour le filaire, comme pour les rivières)


Le 11 mars 2012 22:14, Philippe Verdy  a écrit :
> Le 11 mars 2012 22:03, Vincent Pottier  a écrit :
>>> +5+ des descriptions différentes:
>>> description highway + son "contenu"
>>> junction=roundabout / landuse grass (l'intérieur du giratoire)
>>> highway=residential / amenity=parking (une route autour d'un parking)
>>
>> IMHO, c’est une approximation. les highways sont du filaire de voirie alors
>> que les contenus, parking, grass sont du surfacique... qui ne s'arretent pas
>> à l'axe de la voie.
>>
>> Le cercle d'herbe, dans le rond-point devrait avoir un rayon un peu moindre
>> que le filaire du rond-point. De même pour la route autour du parking, si
>> elle n'est pas un highway=service+service=parking_aisle, (dans ce cas, ce
>> devrait être l'inverse, la surface du parking comprend les voies de parking)
>
> C'est pas bête, sauf que le filaire est lui aussi une approximation
> qui ne précise pas non plus très bien la largeur de la voie. N'importe
> quel moterur de rendu doit d'abord tracer le surfacique, pour ensuite
> afficher par dessus le filaire (auquel il adjoint une épaisseur
> arbitraire, qui recouvre les surfaces.
>
> Bref ce n'est pas une erreur tant qu'on ne tracera pas les routes
> elles aussi en surfacique  et non en filaire (comme on le fait pour
> les rivières dont on continue pourtant à définir un filaire central,
> pour le cas des rendus où le surfacique n'est plus visible et
> nécessiterait de donner une largeur arbitraire mais suffisante à la
> rivière dans le rendu : ce filaire central évite des calculs
> géométriques très compliqués pour déterminer le "squelette" filaire
> d'une surface, un calcul hasardeux qu'aucun moteur de rendu ne sait
> faire correctement pour l'instant, la complexité d'un tel calcul étant
> en O(n²) où n est le nombre de sommets de la surface, n pouvant être
> très grand, ce qui veut dire aussi qu'il peut être très lent s'il est
> fait correctement avec des surfaces définies par des polygones de
> plusieurs milliers de nœuds !). Auquel cas le centre du rond-point
> devra être affiné aussi pour que ces surfaces ne se superposent pas.

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

Re: [OSM-talk-fr] Bypass sur autoroute

[Jean-Francois Nifenecker]

Le 11/03/2012 19:58, didier2020 a écrit :


pour les autoroutes d'ile de france, ce n'est pas emergency_access:
cela sert dans le cadre des travaux important et rarement pour une
deviation provisoire d'accident ou autre (délais de mise en place trop
important : demontage + mise en place des cones de lubeck).



En résumé, après les remarques de Marc et Didier :

highway=service
oneway=no
access=no
barrier=guard_rail
service=bypass

--
Jean-Francois Nifenecker, Bordeaux

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

Re: [OSM-talk-fr] doublon way fermé

[Vincent Pottier]

Le 11/03/2012 22:04, Philippe Verdy a écrit :

Note: je n'ai pas décrit comment on peut automatiquement, et
efficacement, déterminer le sens horaire ou antihoraire d'un segment
sur un contour fermé.

En effet. Mais, ça n'est pas grave. Je ne suis pas sur que ça répondait 
à la question de didier200

--
FrViPofm

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

Re: [OSM-talk-fr] Bypass sur autoroute

[Jean-Francois Nifenecker]

Le 11/03/2012 19:51, Marc Sibert a écrit :

Bonsoir,
Suivant ta propre logique : highway=service


Oups. Bien vu.

--
Jean-Francois Nifenecker, Bordeaux

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

Re: [OSM-talk-fr] doublon way fermé

[Philippe Verdy]

Le 11 mars 2012 22:03, Vincent Pottier  a écrit :
>> +5+ des descriptions différentes:
>> description highway + son "contenu"
>> junction=roundabout / landuse grass (l'intérieur du giratoire)
>> highway=residential / amenity=parking (une route autour d'un parking)
>
> IMHO, c’est une approximation. les highways sont du filaire de voirie alors
> que les contenus, parking, grass sont du surfacique... qui ne s'arretent pas
> à l'axe de la voie.
>
> Le cercle d'herbe, dans le rond-point devrait avoir un rayon un peu moindre
> que le filaire du rond-point. De même pour la route autour du parking, si
> elle n'est pas un highway=service+service=parking_aisle, (dans ce cas, ce
> devrait être l'inverse, la surface du parking comprend les voies de parking)

C'est pas bête, sauf que le filaire est lui aussi une approximation
qui ne précise pas non plus très bien la largeur de la voie. N'importe
quel moterur de rendu doit d'abord tracer le surfacique, pour ensuite
afficher par dessus le filaire (auquel il adjoint une épaisseur
arbitraire, qui recouvre les surfaces.

Bref ce n'est pas une erreur tant qu'on ne tracera pas les routes
elles aussi en surfacique  et non en filaire (comme on le fait pour
les rivières dont on continue pourtant à définir un filaire central,
pour le cas des rendus où le surfacique n'est plus visible et
nécessiterait de donner une largeur arbitraire mais suffisante à la
rivière dans le rendu : ce filaire central évite des calculs
géométriques très compliqués pour déterminer le "squelette" filaire
d'une surface, un calcul hasardeux qu'aucun moteur de rendu ne sait
faire correctement pour l'instant, la complexité d'un tel calcul étant
en O(n²) où n est le nombre de sommets de la surface, n pouvant être
très grand, ce qui veut dire aussi qu'il peut être très lent s'il est
fait correctement avec des surfaces définies par des polygones de
plusieurs milliers de nœuds !). Auquel cas le centre du rond-point
devra être affiné aussi pour que ces surfaces ne se superposent pas.

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

Re: [OSM-talk-fr] doublon way fermé

[Philippe Verdy]

Note: je n'ai pas décrit comment on peut automatiquement, et
efficacement, déterminer le sens horaire ou antihoraire d'un segment
sur un contour fermé. La solution est simple:

- Nos coordonnées étant stockées avec une précision maximale de 32
bits (sur un float), il est toujours possible de convertir ces
coordonnées en double (64 bits) pour y ajouter une quantité espsilon
suffisante permettant de déterminer les coordonnées d'un point de
référence en dehors de tout chemin de la base. Il suffit de multiplier
ces coordonnées (converties en double) par la constante (double 64
bits) = (1 + 2 ^ -47). Donc il suffit de le faire pour le premier nœud
d'un chemin dont on cherche à savoir s'il est en sens horaire ou
antihoraire.

- Ensuite on utilise ce point de référence pour savoir s'il est à
l'intérieur ou à l'extérieur du chemin fermé, en comptant là encore
les points (à l'est comme à l'ouest, peu importe !) où une ligne
horizontale de référence (passant par le point de référence), coupe
les segments du chemin testé (il n'y a aucun point particulier car il
n'y aura aucun chemin horizontal à la même latitude que ce point de
référence !)

- Il n'est même pas nécessaire de déterminer les coordonnées
d'intersection de cette horizontale avec chaque segment, juste de
déterminer d'abord si ce segment a ses deux sommets du même côté de
l'horizontale de références (latitudes toutes deux supérieures ou
toutes deux inférieures, auquel cas il n'y a pas d'intersection
possible) ; sinon le segment est vertical ou oblique et sa droite
coupe nécessairement l'horizontale quelquepart.

- Nul besoin de déterminer où sur l'horizontale, la plupart du temps :
pas de calcul compliqué à faire, ni même de déterminer si
l'intersection avec l'horizontale de la droite porteuse du segment est
située sur ce segment ou pas !), tout ce qu'on voulait savoir c'est si
chaque segment coupe ou pas l'horizontale (ou pourrait le couper si un
sommet de segment était déplacé, sans changer l'orientation horaire,
pour traverser l'horizontale deux fois, une fois chaque segment
partageant ce sommet) .

- Le seul cas est pour les segments verticaux et obliques de savoir si
cette intersection de l'horizontale de référence avec la droite
porteuse de segment est sur le segment ou pas : un calcul linaire
simple avec deux soustraction et une division (dont le diviseur ne
peut pas être nul car on sait que l'intersection de l'horizontale de
référence avec de la droite porteuse du segment existe bien) fournira
le résultat.

- si le nombre d'intersections des droites portant les segments avec
l'horizontale de référence est multiple de 4 (ou nul) on sait alors
que le chemin est dans le sens antihoraire. Sinon ce nombre est pair
mais non multiple de 4 le chemin est en sens horaire... Si le nombre
est impair, le contour n'est pas fermé et il n'a pas de sens
définissable autre que celui qu'il utilise !

Pas besoin de faire de trigo ! Cet algo est extrêmement rapide ! Noter
que tous les calculs effectués avec des double 64-bits sont plus
rapides qu'avec des float (32-bits) à cause des règles d'arrondis IEEE
et les conversions multiples de type pour les résultats
intermédiaires.

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

Re: [OSM-talk-fr] doublon way fermé

[Vincent Pottier]

Le 11/03/2012 14:28, didier2020 a écrit :

pour la france, j'ai comptabilisé plus de 20 000 ways fermé en double:
http://didier2020.free.fr/doublon/

le way fermé etant décrit par ses nodes : 1 2 3 4 1
le premier et le dernier ayant  le meme node
j'ai considéré comme identique les descriptions
1 2 3 4 1
2 3 4 1 2
3 4 1 2 3
4 1 2 3 4
1 4 3 2 1
4 3 2 1 4
3 2 1 4 3
2 1 4 3 2

Bravo pour ce type de recherche qualité !


+5+ des descriptions différentes:
description highway + son "contenu"
junction=roundabout / landuse grass (l'intérieur du giratoire)
highway=residential / amenity=parking (une route autour d'un parking)
IMHO, c’est une approximation. les highways sont du filaire de voirie 
alors que les contenus, parking, grass sont du surfacique... qui ne 
s'arretent pas à l'axe de la voie.
Le cercle d'herbe, dans le rond-point devrait avoir un rayon un peu 
moindre que le filaire du rond-point. De même pour la route autour du 
parking, si elle n'est pas un highway=service+service=parking_aisle, 
(dans ce cas, ce devrait être l'inverse, la surface du parking comprend 
les voies de parking)



barrier=fence / landuse=... ou amenity=... (une zone entouré d'une
délimitation)
Là, le risque, c'est la présence d'un area=yes qui ferait prendre la 
surface comme emprise du "barrier=fence". C'est peut-être prudent de 
garder deux "ways" distincts.

une partie de ces erreurs est déja détecté par osmose :
batiments chevauchants (mais noyé dans la masse) ,multiple inner
polygon.

question:
concerne les point +4+ et +5+ :
est-ce une erreur et dans ce cas comment taguer "proprement"

didier


--
FrViPofm

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

Re: [OSM-talk-fr] doublon way fermé

[Philippe Verdy]

Le 11 mars 2012 14:28, didier2020  a écrit :
> pour la france, j'ai comptabilisé plus de 20 000 ways fermé en double:
> http://didier2020.free.fr/doublon/
>
> le way fermé etant décrit par ses nodes : 1 2 3 4 1
> le premier et le dernier ayant  le meme node
> j'ai considéré comme identique les descriptions
> 1 2 3 4 1
> 2 3 4 1 2
> 3 4 1 2 3
> 4 1 2 3 4
> 1 4 3 2 1
> 4 3 2 1 4
> 3 2 1 4 3
> 2 1 4 3 2

Tu te compliques la vie en cherchant toutes les permutations
possibles. Il suffit juste de repérer par exemple le noeud le plus au
nord (sinon le plus à l'ouest), pour ensuite les trier à partir de
celui-ci dans le sens antihoraire). Ca donne un ordre unique, qui
permet de repérer les doublons facilement.

> j'ai effectué des corrections pour comprendre ces "doublons":
> +1+ batiment en double dans le meme changeset tags identiques

Evidememnt une erreur du contributeur de ce même changeset. Quel outil
permet ça ?

> +2+ batiment en double dans le meme changeset, 1 des 2 avec le tag
> wall=no

là les attributs sont différents, mais pas incompatibles: on fusionne
les attributs.

> +3+ des riverbank en double dans le meme changeset

C'est le même cas que le +1+

> +4+ relation mutlipolygone et un way en double sur l'inner
> http://www.openstreetmap.org/?lat=49.1638239&lon=2.4469579&zoom=18
> cela est aussi valable pour les riverbank, zone clc

Attention: aucun des attributs d'un way référencé en rôle "inner" ne
qualifie pas du tout la relation qui le référence. Le way peut être de
type différent pour désigner un objet différent, et la plupart de ses
atrributs migrés vers la/les relations qui référencent ce way en
"outer" (ou rôle anonyme). Il est normal que ce way soit partagé par
deux objets, l'un entourant l'autre)

> +5+ des descriptions différentes:
> description highway + son "contenu"
> junction=roundabout / landuse grass (l'intérieur du giratoire)
> highway=residential / amenity=parking (une route autour d'un parking)
> barrier=fence / landuse=... ou amenity=... (une zone entouré d'une
> délimitation)
>
> une partie de ces erreurs est déja détecté par osmose :
> batiments chevauchants (mais noyé dans la masse) ,multiple inner
> polygon.

> question:
> concerne les point +4+ et +5+ :
> est-ce une erreur et dans ce cas comment taguer "proprement"

Retenir que tout ce qui est défini pour un rôle "inner" ne concerne
pas l'objet (relation) qui en fait la référence. Un rôle inner n'est
jamais un doublon, sauf si la même relation référence deux fois ce way
pour un rôle inner, auquel cas il faudrait fusionner les zones inner
qui se touchent en réduisant le nombre de ways dans la relation.

Si on était logique d'ailleurs, la mention des rôles inner et outer
serait inutile et on pourrait se contenter du rôle anonyme, car il est
toujours possible de déterminer *automatiquement* si un chemin fait
partie du contour externe ou du contour interne d'un objet.

Ce qui veut dire en pratique que dans un premier temps il suffit de
prendre tous les ways d'une relation en même temps, qu'ils soient de
rôle anonyme, inner ou outer, détecter les ways en doublons dans cette
liste, puis détecter les intersections (sur un noeud interne des ways,
ou sur un nouveau noeud ajouté). En cas d'interection nécessitant un
nouveau noeud calculé, on l'insère dans chaque way.

Ensuite on tri les noeuds de chaque way en partant arbitrairement du
noeud le plus au nord (ou le plus à l'ouest en cas de latitude égale)
parmi  les deux noeuds d'extrémité (pour un way non fermé) ou parmi
tous les noeuds du way (s'il est fermé, c'est à dire ses deux
extrémités sont au même point). Attention pendant ce tri, il faut
préserver la direction si c'est un way pour une route ou une rivière
(mais pas si le way désigne une surface, car alors la direction n'est
plus pertinente, ce qui est mentionné par un tag spécifique
déterminant la signification des ways fermés). Si la direction n'est
pas pertinente, on inverse les sens de parcours à partir du point
déterminé.

On fait attention à cette étape aux noeuds superposés : il y a des cas
pour lesquels deux noeuds peuvent exister dans la base uniquement
parce qu'ils ont des attributs différents (à cause de leur altitude).
Sinon ces noeuds sont à fusionner (fusion des attributs vers le noeuds
avec l'ID le plus petit, c'est à dire le plus ancien).

Alors seulement on a des listes de ways comparables : on peut ensuite
déterminer les ways qui se superposent au moins en partie (auquel cas
il faudra scinder ces ways en plusieurs parties, sans omettre
d'ajouter les nouveaux ways créés à la totalité des relations qui
référencent le way non scindé). Il ne reste laors plus que des ways
soit entièrement égaux dans leur géométrie (noeuds et directions),
soit des ways dont les listes de noeuds sont en sens inverse (lignes
centrales des routes et cours d'eaux;  pour ces derniers il faut
relaver l'erreur ou utiliser un algo plus avancé car il n'est pas
toujours évident de déterminer quelle est la bonne direction à garder;
pour les r

Re: [OSM-talk-fr] Bypass sur autoroute

[didier2020]

Le dimanche 11 mars 2012 à 16:40 +0100, Jean-Francois Nifenecker a
écrit :
> Bonjour,
> 
> je suis en train de réviser l'OSMecum "sur l'autoroute" et je me demande 
> comment étiqueter les bypass qui permettent les basculements provisoires 
> de voie. Je n'ai rien trouvé sur les Map features (EN ni FR). TagInfo ne 
> trouve pas grand chose (1 bypass, 55 chemins tagués barrier_bypass)
> 
> Pour ma part je tracerais un micro-way entre les deux voies et lui 
> mettrais les étiquettes :
> highway=unclassified
service ?
> oneway=no
> access=no
> barrier=guard_rail
> service=emergency_access (ou service=bypass ?)

pour les autoroutes d'ile de france, ce n'est pas emergency_access:
cela sert dans le cadre des travaux important et rarement pour une
deviation provisoire d'accident ou autre (délais de mise en place trop
important : demontage + mise en place des cones de lubeck).


> Avec Bing, il est très facile de repérer ces bypass.

didier
xYx


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

Re: [OSM-talk-fr] Bypass sur autoroute

[Marc Sibert]

Bonsoir,
Suivant ta propre logique : highway=service
A+
Marc

- Message d'origine -
De: Jean-Francois Nifenecker 
Env: dimanche 11 mars 2012 16:40
À: Discussions sur OSM en français 
Objet: [OSM-talk-fr] Bypass sur autoroute

Bonjour,

je suis en train de réviser l'OSMecum "sur l'autoroute" et je me demande 
comment étiqueter les bypass qui permettent les basculements provisoires 
de voie. Je n'ai rien trouvé sur les Map features (EN ni FR). TagInfo ne 
trouve pas grand chose (1 bypass, 55 chemins tagués barrier_bypass)

Pour ma part je tracerais un micro-way entre les deux voies et lui 
mettrais les étiquettes :
highway=unclassified
oneway=no
access=no
barrier=guard_rail
service=emergency_access (ou service=bypass ?)

Avec Bing, il est très facile de repérer ces bypass.

Amicalement,
-- 
Jean-Francois Nifenecker, Bordeaux

___
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] Éoliennes : doublon de tag power source

[yvecai]

A priori le tag doit aussi être importé dans la base de donnée de rendu 
si j'en crois celà:

http://trac.openstreetmap.org/log/applications/utils/export/osm2pgsql/default.style

Yves

Le 11/03/2012 18:09, Vincent Privat a écrit :
A priori le problème a été (enfin ...) corrigé côté Mapnik, le nouveau 
tag doit être rendu maintenant:

http://trac.openstreetmap.org/ticket/3266#comment:10

Le 11 mars 2012 12:49, Francisco DOS SANTOS > a écrit :



Bonjour,

Une situation plutôt "embarrassante" qui perdure depuis un moment, le
tag power_source est déprécié en faveur du tag generator:source.
Le vieux tag n'est même plus mentionné dans le wiki, remplacé par une
redirection.

Seulement voilà, pour le rendu il ne faut pas juste changé la
feuille de
style mais aussi la base de donnée mapnik :
http://trac.openstreetmap.org/ticket/3266

On se retrouve donc avec un tag déprécié dont on fait le rendu et
un tag
recommandé qui n'est pas affiché.

Du coup on tombe sur des cas où ces 2 tags sont utilisés en même
temps,
un exemple ici :
http://www.openstreetmap.org/?lat=44.44592&lon=4.74962&zoom=16&layers=M


Le changeset qui a rajouté en masse le tag pour le rendu :
http://www.openstreetmap.org/browse/changeset/10690119

J'ai bien sur laissé un message à l'auteur en lui signalant que
l'on ne
taggue pas pour le rendu, pour l'instant pas de réponse :

http://wiki.openstreetmap.org/wiki/Best_practices#Don.27t_map_for_the_renderer

Francisco


___
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] Éoliennes : doublon de tag power source

[Vincent Privat]

A priori le problème a été (enfin ...) corrigé côté Mapnik, le nouveau tag
doit être rendu maintenant:
http://trac.openstreetmap.org/ticket/3266#comment:10

Le 11 mars 2012 12:49, Francisco DOS SANTOS  a écrit :

>
> Bonjour,
>
> Une situation plutôt "embarrassante" qui perdure depuis un moment, le
> tag power_source est déprécié en faveur du tag generator:source.
> Le vieux tag n'est même plus mentionné dans le wiki, remplacé par une
> redirection.
>
> Seulement voilà, pour le rendu il ne faut pas juste changé la feuille de
> style mais aussi la base de donnée mapnik :
> http://trac.openstreetmap.org/ticket/3266
>
> On se retrouve donc avec un tag déprécié dont on fait le rendu et un tag
> recommandé qui n'est pas affiché.
>
> Du coup on tombe sur des cas où ces 2 tags sont utilisés en même temps,
> un exemple ici :
> http://www.openstreetmap.org/?lat=44.44592&lon=4.74962&zoom=16&layers=M
>
> Le changeset qui a rajouté en masse le tag pour le rendu :
> http://www.openstreetmap.org/browse/changeset/10690119
>
> J'ai bien sur laissé un message à l'auteur en lui signalant que l'on ne
> taggue pas pour le rendu, pour l'instant pas de réponse :
>
> http://wiki.openstreetmap.org/wiki/Best_practices#Don.27t_map_for_the_renderer
>
> Francisco
>
>
> ___
> 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] Bypass sur autoroute

[Jean-Francois Nifenecker]

Bonjour,

je suis en train de réviser l'OSMecum "sur l'autoroute" et je me demande 
comment étiqueter les bypass qui permettent les basculements provisoires 
de voie. Je n'ai rien trouvé sur les Map features (EN ni FR). TagInfo ne 
trouve pas grand chose (1 bypass, 55 chemins tagués barrier_bypass)


Pour ma part je tracerais un micro-way entre les deux voies et lui 
mettrais les étiquettes :

highway=unclassified
oneway=no
access=no
barrier=guard_rail
service=emergency_access (ou service=bypass ?)

Avec Bing, il est très facile de repérer ces bypass.

Amicalement,
--
Jean-Francois Nifenecker, Bordeaux

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

[OSM-talk-fr] doublon way fermé

[didier2020]

pour la france, j'ai comptabilisé plus de 20 000 ways fermé en double:
http://didier2020.free.fr/doublon/

le way fermé etant décrit par ses nodes : 1 2 3 4 1 
le premier et le dernier ayant  le meme node
j'ai considéré comme identique les descriptions
1 2 3 4 1
2 3 4 1 2 
3 4 1 2 3
4 1 2 3 4
1 4 3 2 1
4 3 2 1 4
3 2 1 4 3
2 1 4 3 2

j'ai effectué des corrections pour comprendre ces "doublons":
+1+ batiment en double dans le meme changeset tags identiques

+2+ batiment en double dans le meme changeset, 1 des 2 avec le tag
wall=no

+3+ des riverbank en double dans le meme changeset 

+4+ relation mutlipolygone et un way en double sur l'inner
http://www.openstreetmap.org/?lat=49.1638239&lon=2.4469579&zoom=18
cela est aussi valable pour les riverbank, zone clc

+5+ des descriptions différentes:
description highway + son "contenu"
junction=roundabout / landuse grass (l'intérieur du giratoire)
highway=residential / amenity=parking (une route autour d'un parking)
barrier=fence / landuse=... ou amenity=... (une zone entouré d'une
délimitation)

une partie de ces erreurs est déja détecté par osmose :
batiments chevauchants (mais noyé dans la masse) ,multiple inner
polygon.

question:
concerne les point +4+ et +5+ :
est-ce une erreur et dans ce cas comment taguer "proprement"

didier


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

Re: [OSM-talk-fr] plugin osmose et josm 5047

[didier2020]

c'est parfait !

didier


Le dimanche 11 mars 2012 à 11:50 +0100, Frédéric Rodrigo a écrit :
> Finalement j'ai fait une petite mise à jour :
> Le plugin est disponible là :
> http://f.rodrigo.free.fr/tmp/josm/
> 
> Pour l'installation d'un plugin manuellement voir le wiki :
> http://wiki.openstreetmap.org/wiki/JOSM/Linux#Manually_install_JOSM_plugins
> 
> Frédéric.
> 
> On 08/03/2012 19:36, Frédéric Rodrigo wrote:
> > On 08/03/2012 18:40, Vincent Privat wrote:
> >> On a changé plusieurs choses sur la gestion des plugins avec cette
> >> version.
> >> C'est transparent pour ceux qui sont hébergés sur le Trac OSM, pas pour
> >> les autres, qui doivent s'assurer de rester en phase avec les
> >> modifications effectuées coté JOSM.
> >> Pourquoi ce plugin n'est-il pas hébergé avec les autres ? ça simplifie
> >> pas mal de choses :)
> >
> > Parceque ça ne doit pas être un vrais plugin :/.
> >
> > Ce plugin est issue d'un fork du plugin pour OpenStreetBug avec le quel
> > il partage 98% du code. Jocelyn avait contacté l'auteur de ce plugin
> > pour voir s'il était possible de faire un plugin commun. Malheureusement
> > l'auteur ne veut pas consacrer du temps à maintenir son plugin. C'est la
> > même chose pour moi. En tout et pour tout je n'ai pas du y consacrer
> > plus de 3h.
> >
> > Le ou je veux en venir c'est qu'il partage trop de code avec
> > OpenStreetBug, et que personne ne veut faire l'effort de le maintenir.
> > De plus je trouve son fonctionnement interne pas très élégant. Je
> > considère ce plugin plus comme un hack qu'un vrais plugin... Cet les
> > raisons pour les quelles je n'en ai jamais fait la promotion.
> >
> > Si quelqu'un veux faire l'effort d'intégration et de maintenance, libre
> > à lui...
> >
> > Le plugin permet de clôturer environ 10 000 signalements par mois.
> 
> ___
> 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] Éoliennes : doublon de tag power source

[Francisco DOS SANTOS]

Bonjour,

Une situation plutôt "embarrassante" qui perdure depuis un moment, le
tag power_source est déprécié en faveur du tag generator:source.
Le vieux tag n'est même plus mentionné dans le wiki, remplacé par une
redirection.

Seulement voilà, pour le rendu il ne faut pas juste changé la feuille de
style mais aussi la base de donnée mapnik :
http://trac.openstreetmap.org/ticket/3266

On se retrouve donc avec un tag déprécié dont on fait le rendu et un tag
recommandé qui n'est pas affiché.

Du coup on tombe sur des cas où ces 2 tags sont utilisés en même temps,
un exemple ici :
http://www.openstreetmap.org/?lat=44.44592&lon=4.74962&zoom=16&layers=M

Le changeset qui a rajouté en masse le tag pour le rendu :
http://www.openstreetmap.org/browse/changeset/10690119

J'ai bien sur laissé un message à l'auteur en lui signalant que l'on ne
taggue pas pour le rendu, pour l'instant pas de réponse :
http://wiki.openstreetmap.org/wiki/Best_practices#Don.27t_map_for_the_renderer

Francisco


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

Re: [OSM-talk-fr] Marques, symboles... pour une itinéraire balisé?

[Romain MEHUT]

D'après la page Wikipédia indiquée par Gilles, on emploierait plutôt
"blaze" pour les balises peintes et "marker" pour celles en plastique, bois
ou metal. J'ai bon?

Le 11 mars 2012 00:58, Pieren  a écrit :

> > Je viens de poster la proposition sur la liste internationale
> > tagg...@osm.org:
> > http://lists.openstreetmap.org/pipermail/tagging/2012-March/009520.html
>
> Bon ben, il n'y a pas un consensus clair sur la valeur du tag
> "information" (mais pour le reste, c'est bon).
> "information=trail_blaze" pourrait aller mais il faudrait aussi voir
> avec "information=maker" ou "trail_marker".
>
> 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] Guipel (FR-35)

[Romain MEHUT]

Le 11 mars 2012 11:40, Pieren  a écrit :

> 2012/3/11 Romain MEHUT :
> > - au Nord-Ouest sur la commune de Dingé il y a un repère nommé "Pylône
> No15,
> > support de ligne électrique" mais la ligne électrique est nettement plus
> au
> > Sud;
>
> Rien ne dit que le pylône mentionné fasse partie de la ligne haute
> tension nettement plus au sud. C'est probablement un pylone près du
> bâtiment existant. Le décalage ne doit être que d'un mètre ou deux.
>

Faudrait que quelqu'un en local puisse aller vérifier...

 > - à l'Ouest du bourg de Guipel, il y a 3 repères pour un même château
> d'eau
> > et tous à l'extérieur du cercle le représentant issu du cadastre;
>
> L'exemple le plus intéressant. Je n'ai pas regardé l'historique des
> objets OSM mais si personne n'a déplacé les éléments depuis leur
> import, le bâti cadastral est décalé d'un mètre à l'ouest et
> l'imagerie Bing, d'un mètre à l'est. Les repères géodésiques étant LA
> référence, ce sont les autres qui sont faux (cadastre, Bing).
>

J'ai vérifié. Ils n'ont pas été déplacés.


>  > - dans le bourg, le repère du clocher de l'église.
>
> Là, ça colle presque parfaitement (il faut aussi tenir compte de la
> déformation entre l'emprise au sol et le toit). Bing reste en léger
> décalage mais ça reste dans le domaine de l'acceptable comme pour les
> autres exemples cités (< 5 mètres). Hey, les gars, il ne faut pas
> oublier qu'aux débuts d'OSM, il n'y avait pas d'imagerie aérienne, ni
> de cadastre. Et qu'ensuite il y a eu Yahoo et que ce genre de bled,
> c'était un gros pâté tâché avec du vert et du gris. Alors ne venez pas
> râler quand Bing et le cadastre sont en décallage d'un mètre ou deux
> ;-) Il y a plein d'endroits dans le monde où ils seraient bien
> contents d'avoir des sources de la même qualité que les nôtres.
>

Bon je vais donc me reposer sur Bing et ma trace GPS plutôt que sur le
cadastre.


> 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] plugin osmose et josm 5047

[Frédéric Rodrigo]

Finalement j'ai fait une petite mise à jour :
Le plugin est disponible là :
http://f.rodrigo.free.fr/tmp/josm/

Pour l'installation d'un plugin manuellement voir le wiki :
http://wiki.openstreetmap.org/wiki/JOSM/Linux#Manually_install_JOSM_plugins

Frédéric.

On 08/03/2012 19:36, Frédéric Rodrigo wrote:

On 08/03/2012 18:40, Vincent Privat wrote:

On a changé plusieurs choses sur la gestion des plugins avec cette
version.
C'est transparent pour ceux qui sont hébergés sur le Trac OSM, pas pour
les autres, qui doivent s'assurer de rester en phase avec les
modifications effectuées coté JOSM.
Pourquoi ce plugin n'est-il pas hébergé avec les autres ? ça simplifie
pas mal de choses :)


Parceque ça ne doit pas être un vrais plugin :/.

Ce plugin est issue d'un fork du plugin pour OpenStreetBug avec le quel
il partage 98% du code. Jocelyn avait contacté l'auteur de ce plugin
pour voir s'il était possible de faire un plugin commun. Malheureusement
l'auteur ne veut pas consacrer du temps à maintenir son plugin. C'est la
même chose pour moi. En tout et pour tout je n'ai pas du y consacrer
plus de 3h.

Le ou je veux en venir c'est qu'il partage trop de code avec
OpenStreetBug, et que personne ne veut faire l'effort de le maintenir.
De plus je trouve son fonctionnement interne pas très élégant. Je
considère ce plugin plus comme un hack qu'un vrais plugin... Cet les
raisons pour les quelles je n'en ai jamais fait la promotion.

Si quelqu'un veux faire l'effort d'intégration et de maintenance, libre
à lui...

Le plugin permet de clôturer environ 10 000 signalements par mois.


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

Re: [OSM-talk-fr] Guipel (FR-35)

[Pieren]

2012/3/11 Romain MEHUT :
> - au Nord-Ouest sur la commune de Dingé il y a un repère nommé "Pylône No15,
> support de ligne électrique" mais la ligne électrique est nettement plus au
> Sud;

Rien ne dit que le pylône mentionné fasse partie de la ligne haute
tension nettement plus au sud. C'est probablement un pylone près du
bâtiment existant. Le décalage ne doit être que d'un mètre ou deux.

> - à l'Ouest du bourg de Guipel, il y a 3 repères pour un même château d'eau
> et tous à l'extérieur du cercle le représentant issu du cadastre;

L'exemple le plus intéressant. Je n'ai pas regardé l'historique des
objets OSM mais si personne n'a déplacé les éléments depuis leur
import, le bâti cadastral est décalé d'un mètre à l'ouest et
l'imagerie Bing, d'un mètre à l'est. Les repères géodésiques étant LA
référence, ce sont les autres qui sont faux (cadastre, Bing).

> - dans le bourg, le repère du clocher de l'église.

Là, ça colle presque parfaitement (il faut aussi tenir compte de la
déformation entre l'emprise au sol et le toit). Bing reste en léger
décalage mais ça reste dans le domaine de l'acceptable comme pour les
autres exemples cités (< 5 mètres). Hey, les gars, il ne faut pas
oublier qu'aux débuts d'OSM, il n'y avait pas d'imagerie aérienne, ni
de cadastre. Et qu'ensuite il y a eu Yahoo et que ce genre de bled,
c'était un gros pâté tâché avec du vert et du gris. Alors ne venez pas
râler quand Bing et le cadastre sont en décallage d'un mètre ou deux
;-) Il y a plein d'endroits dans le monde où ils seraient bien
contents d'avoir des sources de la même qualité que les nôtres.

Pieren

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

[OSM-talk-fr] Guipel (FR-35)

[Romain MEHUT]

Bonjour,

En février, j'ai passé une après-midi sur la commune de Guipel en
Ile-et-Vilaine où j'ai parcouru les sentiers balisés des Guipellois et de
la Barre: http://www.valdille.fr/index.php/les-sentiers-de-randonnee.html

Avant d'ajouter dans OSM les données recueillies avec mon GPS, j'ai regardé
globalement la cartographie déjà existante. J'ai commencé par recaler
quelques routes avec Bing et j'ai remarqué que le tag source était
inhabituel: "Mairie de Guipel, juin 2010". En cherchant dans les archives
de la liste, je me suis rendu compte qu'il y avait eu un import des données
du filaire routier communiquées par la collectivité. (Je n'étais pas encore
à l'époque contributeur OSM ni inscrit sur la mailing liste).

Maintenant, avant de poursuivre, est-ce que vous pourriez me donner votre
avis sur le bon calage ou pas de Bing et du cadastre? En effet, d'après les
repères géodésiques en place, c'est pas si évident:
- au Nord-Ouest sur la commune de Dingé il y a un repère nommé "Pylône
No15, support de ligne
électrique"
mais la ligne électrique est nettement plus au Sud;
- à l'Ouest du bourg de Guipel, il y a 3 repères pour un même château
d'eauet
tous à l'extérieur du cercle le représentant issu du cadastre;
- dans le bourg, le repère du
clocherde
l'église.

Merci pour votre aide.

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