Re: [OSM-talk-fr] Rendu FR: correction premiers zooms...

[Philippe Verdy]

les trapèzes, c'est pas terrible, il vaut mieux faire un raccordement
"sinusoïdal" tenant compte de la largeur de route pour que les coins
ajoutés aux jonctions fasse un angle assez aigu (pas plus de 30 degrés). Ca
donne les premiers points de contrôle fixes; ensuite on peut ajouter sur
les diagonales divisées en 3 parties égales des points  qu'on déplace pour
qu'il s'alignent parallèlement à la route au point de raccordement médian,
et on en fait des points de contrôle directionnels pour une courbe de
Bézier qu'on peut ensuite découper en petits segments pour former la
courbe, autant qu'on a envie.

La difficulté c'est qu'au point de jonction entre les segments tracés dans
OSM à 2 voies et ceux à trois voies, ils ne sont pas parfaitement
colinéaires et il faut en tenir compte en utilisant les médiatrices des
orthogonales pour déterminer l'orthogonale moyenne du raccordement à partir
desquels on détermine les 2 segments à 90° et à 90°+30° devant découper
chaque côté de la jonction. pour déterminer les points fixes de terminaison
des courbes de Béziers (celles à partir desquelles on fait ensuite
l'approximation en petits segments quasi colinéaires).

L'autre difficulté c'est qu'un des deux segments de chaque côté peut ne pas
être assez long pour assurer un angle de 30° permettant de le découper en
ajoutant le coin dans la première étape (celle avant de créer les Béziers),
 la contrainte de 30° maxi pour le biseau doit être alors levée en
utilisant une diagonale simple mais ensuite l'étape de calcul des points
 de controle supplémentaires reste la même pour assurer la
quasi-colinéarité aux extrémités quand ce coin biseauté est retaillé en
fine pointe courbée.

Une autre solution c'est des raccordements avec des cercles dont le rayon
égale la largeur de la route. Comme il y a un changement du nombre de
voies, on a aussi changement de cette largeur (estimée à partir du nombre
de "lanes", ou précisée en mètres dans les chemins OSM); ces cercles vont
donc aussi avoir des rayons devant suivre une courbe d'ajustement.

Noter aussi que les coins à 30° c'est pour des routes urbaines, mais c'est
encore trop pour les routes à 90km/h ou plus (mais si on prend moins, on
peut tomber plus facilement sur le cas des biseaux qui dépassent la
longueur du tronçon de voie le long du quel on ajoute ou retranche les
biseaux (il y a deux biseaux, un du côté où la largeur est plus petite et
où on ajoute le biseau, l'autres du côté où la largeur es plus grande et où
on coupe ce biseau).

Une autre façon de faire est de redécouper les segments pour avoir à des
largeurs intermédiaires: à la distance d'une extrémité correspondant à la
largeur de la voie, cette largeur s'écarte de 25% environ, et à 2 fois
cette distance, cette largeur s'écarte de 75%, à 3 fois cette distance,
cette largeur atteint 100%: on peut utiliser ça pour ajouter d'autres
points intermédiaire par une lissage de Bézier (une quadratique devrait
suffire, pas besoin de cubique mais ce n'est pas vraiment plus compliqué
avec la méthode de Bézier). Là on peut alors utiliser les trapèzes pour
joindre le tout.



Le 2 septembre 2017 à 19:45, Christian Quest  a
écrit :

> Le 02/09/2017 à 15:00, marc marc a écrit :
>
>> Le 02. 09. 17 à 09:34, Christian Quest a écrit :
>>
>>> corrigé et tuiles recalculées. C'est quand même mieux !
>>>
>> +1
>>
>> est-ce tu prévois une maj avec les autres améliorations
>> qui ont eu lieu sur la version mondiale ?
>> j'ignore sur le fork rend ce genre de fusion facile ou non.
>>
>
> Le fork est tellement ancien que c'est bien compliqué de reprendre des
> améliorations...
>
> est-ce possible de soumettre d'autres améliorations ?
>>
>
> Oui, bien sûr, ensuite c'est en fonction de mon temps dispo que je m'y
> met, souvent en groupant car il faut un peu de tmeps pour se remettre dans
> le bain ;)
>
> je pense par exemple à la prise en compte du nombre de bande
>> d'une rue pour les zooms élevé
>> en première approximation, une rue avec lanes=3 devrait
>> apparaître 3x plus large qu'une rue avec lanes=1
>>
>
> Oh, ça... j'ai déjà essayé et c'est affreux sur les raccords. Il suffit de
> voir ce que ça donne dans JOSM avec le style qui montre la largeur des
> voies.
>
> Il faudrait dessiner en trapèze les zone où le nombre de voies change et
> je n'ai pas trouvé de moyen simple pour faire ça.
>
> Par contre, d'autres choses pourraient devenir visibles: ligne continue ou
> pas, voire absente par exemple mais je pense qu'on a des trucs bien plus
> prioritaires à rendre visibles avant ça, non ?
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] a sample panoramic aerial image for 3D mapping made with the new DJI Spark quad-copter

[Warin]

On 03-Sep-17 12:53 AM, Andy Mabbett wrote:

On 1 September 2017 at 14:37, Oleksiy Muzalyev
 wrote:


I received today my new DJI Spark quad-copter and made a panoramic aerial
image with it:

Impressive pic.

Curious about the drone, I found this review:

 https://www.youtube.com/watch?v=_eYGih4FI8c

and now I want one!



While I may want one, I also know there are legal restrains on it use. These 
are local.

Suggest you check for local regulations for there use, and if you want to 
travel with one then the regulations there too.

If your going to Egypt .. don't take a drone as they are illegal will be 
confiscated at the boarder and some have been detained for some time due to 
having one.

Having read the regulations .. I'm not getting one. Too restrictive and 
subjective observations may have trouble develop.


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

[Talk-cz] Fw: hey! so exciting

[Lukas Gebauer]

Greetings! 

Look  what I've found  on the web, this is something new I guess, you'll  be 
excited. More information here 
http://natoquest.org/www/administrator/help/en-GB/surgeon.php?UE90YWxrLWN6QG9wZW5zdHJlZXRtYXAub3Jn

Hope this helps, Lukas Gebauer



From: OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org]
Sent: Saturday, September 02, 2017 5:42 PM
To: 2...@centrum.cz
Subject: friend request sent

La PPP  est un concept debile  au possible. Ca dit  en gros qu'un bien 
identique coute moins cher car  il y  a moins d'infrastructures a payer autour. 
Ces  infrastructures autour se payent ...

Quand on va au  supermarche on paye tout sauf  les produits. On paye 
l'assurance,  la retraite  et l'ecole  des salaries,  les normes de  securite 
pour avoir  moins d'accidents du  travail, le reseau electrique stable, la 
police et l'administration  qui font  leur  boulot, les espaces verts  devant 
le supermarche,  la route, les lumieres exterieures, etc,  etc, etc.


La PPP consiste a regarder le prix  du pot de Nutella et  de dire qu'il coute 
plus cher en France qu'en Pologne.

La PPP est un  concept consumerisme qui  enleve toute la  qualite  de  vie non 
marchande. L'ideal  selon la  PPP, c'est des inegalites  monstrueuse  avec des 
esclaves sans aucune  protection,  comme ca le cout de la vie est bas.


Sent from Mail for Windows 10___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] Stations service rue de Rivoli

[Frédéric Rodrigo]

Les données utilisées pour cette analyses ne sont pas automatiquement 
mise à jour.
J'ai corrigé le problème en ignorant les coordonnées et mis à jour les 
données.
Il faut attendre le prochain lancement de l'analyse (2j) pour avoir une 
mise à jour des données dans Osmose.


Frédéric.


Le 02/09/2017 à 22:39, Francois Gouget a écrit :

On Wed, 30 Aug 2017, Frédéric Rodrigo wrote:


J'ai exclus les points avec ces coordonnées.
Ça sera pris en compte avec les prochaines mise à jour code d'Osmose.

Ce qui est bizarre c'est qu'à l'heure actuelle la station essence qui
est sur le dessus de la pile rue de Rivoli a la référence 34410006. Si
je la recherche dans PrixCarburants_annuel_2017.xml je trouve :


   Route de Valras Plage
   Srignan

Or les coordonnées du fichier, (43.2827033, 3.2802886) pointent sur la
rue Rouget de l'Isle ***à Sérignan***. Les coordonnées ne sont donc
probablement pas tout à fait correctes puisqu'elles ne correspondent pas
à la route de Valras Plage et que je ne vois pas de station essence à
proximité. Mais si Osmose place le point dans Paris ce n'est pas à
cause de ces coordonnées.

Est-ce qu'Osmose ignore complètement les coordonnées GPS du fichier et
fait sa propre géolocalisation à partir de l'adresse ? Car effectivement
OpenStreetMap ne trouve pas la route de Valras Plage. Du coup on se
retrouverait avec des coordonnées par défaut qui seraient rue de Rivoli ?

Mais faut-il vraiment ignorer les coordonnées GPS du fichier ?

Même si le géocodage du fichier n'est pas très bon, refaire le notre ne
donnera pas forcément de meilleurs résultats :
* Les adresses sont souvent incomplètes. Par exemple il leur manque
   souvent le numéro de rue (même pour des vraies rues).
* Si je ne me trompe OpenStreetMap n'a de toute façon souvent pas le
   numéro de rue.
* Et il manque encore des adresses dans OpenStreetMap (comme ici).





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

Re: [Talk-es] Asqueado de que Google Maps te pregunte cosas, ayuda a OpenStreetmap

[Antonio Clavero]

+1 
Muy bueno

Enviado desde mi iPhone

> El 2 sept 2017, a las 18:51, Manu El  escribió:
> 
> Muy bueno. He compartido por mis redes sociales el artículo.
> 
> Manuel.
> 
> El 1 de septiembre de 2017, 12:15, Miguel de Dios Matias 
>  escribió:
>> Buenas gente.
>> 
>> He hecho un pequeño articulo en mi blog personal sobre StreetComplete, la 
>> app para Android para ayudar a OSM.
>> 
>> http://www.tomatesasesinos.com/2017/09/01/asqueado-de-que-google-maps-te-pregunte-cosas-ayuda-a-openstreetmap/
>> 
>> Supongo que tendrá algún que otro error ortográfico, mil perdones.
>> 
>> Si veis que falta algo o algo que mejorar en el artículo, de mil amores lo 
>> arreglo.
>> 
>> Saludos.
>> 
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>> 
> 
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] Importanza strada provinciale.

[Lorenzo Mastrogiacomi]

Il giorno sab, 02/09/2017 alle 11.06 -0500, vrmap ha scritto:
> Nella mia zona c'è una strada provinciale che collega due località poste in
> due Comuni diversi denominata SP14. 
> Nella pagina wiki è riportato che per questa tipologia di strade va mapapta
> come highway=secondary. 
> La parte centrale di questa strada provinciale, sviluppandosi in quota, non
> è pavimentata e risulta molto meno frequentata dalle autovetture rispetto
> alla sua parte iniziale e finale. 
> In questi casi, secondo voi è giusto mappare tutto il tracciato come
> higway=secondary oppure, essendo la parte centrale non pavimentata/meno
> frequentata/meno importante, mappare la parte centrale con
> highway=unclassified ed il resto come highway=secondary?  
> 

Non deve per forza essere una secondary, puo' benissimo essere tertiary
o anche di grado inferiore se di scarsa importanza.
In generale se la strada finisce col collegarsi a strade piu'
importanti ad entrambi i capi dovrebbe essere mappata tutta con lo
stesso grado. Se invece ad un capo si ramifica e termina in zone
isolate puo' aver senso diminuire il grado alle biforcazioni man mano
che perde di importanza.


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

[OSM-talk] Chaotic mapping by a new user in Sweden

[Andreas Vilén]

Hi,

About a week ago edits against the editing norm in the village of Veberöd
in Sweden ( http://www.openstreetmap.org/user/Linus%20Olsson/history ) was
noticed by me and Essin, who are both active editors in this region in
Sweden. I first tried writing a changeset message telling him his edits are
appreciated, but he should read up on editing norms and look in other
areas, and that his edits will probably be reverted. I also recommended
some ways to contact the community (
http://www.openstreetmap.org/changeset/51485420 ). This didn't help though
and he's still editing, now starting to edit bigger roads which can have a
bigger impact on routing than the misguided edits inside the village (that
still break routing though).

I tried to send an email to DWG explaining this, but have got no reply a
week after I sent it. I tried reverting with the only means I know, the
Revert UI. It didn't work since someone had already edited relations in the
area. Essin has said he could be willing to try to revert in Josm, but a
more experienced hand might be needed.

Below I'm including the email I sent to DWG with more details.

"I would like to ask for some help reverting edits by a new user in Veberöd
in Sweden. The user made a lot of small edits in ID over the past week and
have for example 1) changed highway tags https://www.openstreetmap.org/
way/311389509/history , 2) drawn separate ways in either direction even for
residential streets https://www.openstreetmap.org/#map=19/55.63105/13.50659 ,
3) drawn complex overlapping streets for simple intersections
https://www.openstreetmap.org/#map=19/55.63327/13.49399 4) broken
relations, 5) drawn separate foot/cycleways when in reality they are the
same way and finally 6) started attempts at editing, probably gotten
confused and simply uploaded broken data

The edits can be seen here: https://www.openstreetmap.org/
user/Linus%20Olsson/history

The biggest mess is probably this roundabout: https://www.
openstreetmap.org/#map=19/55.63395/13.49738 or here: https://www.
openstreetmap.org/#map=19/55.63522/13.49057

I have contacted the mapper in a changeset comment and tried to write an
encouraging message that edits are welcome but as a new user he should be a
little careful before he starts reinventing the way we map (in Swedish, I
can translate if necessary): http://www.openstreetmap.org/changeset/51485420 I
suspect no ill intent.

I also tried to revert myself with http://revert.osmz.ru but was
unsuccessful, since someone has edited relations after his latest edit.

I feel it's a bit beyond my editing skills to try to revert all of this
manually, and not miss anything or by accident delete history. I also
believe the user has already deleted history and replaced streets with
streets drawn by him.

It would be nice if you could be of help in reverting all of this, before
people start reverting small bits of it and mess up the data even more."

Can we get some help here please with either reverting or blocking if he
doesn't stop editing against conventions?

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

Re: [Talk-it] canalina che attraversa strada forestale

[Volker Schmidt]

layer=-1 secondo me non va bene, la canaletta non è sotto la strada. Il
ruscello e la strada si incontrano sullo stesso livello. Ache "drain" non
va benefits, è una categoria di waterway e non un manufatto che permette a
un corso d'acqua di attraversare una strada, come un ponte o una galleria o
un guado.

On 2 Sep 2017 22:59, "demon.box"  wrote:

> ...nel frattempo mi è venuto in mente, per il solo tratto del canale di
> scolo:
>
> waterway=drain
> layer=-1
>
> potrebbe starci...
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-us] Corpus Christi Building Import to aid in Harvey Recovery

[Clifford Snow]

The Corpus Christi building import [1] wiki page is available. Basically
this import is to add building outlines provided by Microsoft [1] to aid in
Harvey Recovery efforts. It uses the OSM US Task Manager with project 118
to facilitate the import.


[1] https://wiki.openstreetmap.org/wiki/Corpus_christi_import
[2] https://wiki.openstreetmap.org/wiki/Microsoft_Building_Footprint_Data

Best,
Clifford Snow

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Importanza strada provinciale.

[Andrea Musuruane]

2017-09-02 18:06 GMT+02:00 vrmap :

> Nella mia zona c'è una strada provinciale che collega due località poste in
> due Comuni diversi denominata SP14.
> Nella pagina wiki è riportato che per questa tipologia di strade va mapapta
> come highway=secondary.
> La parte centrale di questa strada provinciale, sviluppandosi in quota, non
> è pavimentata e risulta molto meno frequentata dalle autovetture rispetto
> alla sua parte iniziale e finale.
> In questi casi, secondo voi è giusto mappare tutto il tracciato come
> higway=secondary oppure, essendo la parte centrale non pavimentata/meno
> frequentata/meno importante, mappare la parte centrale con
> highway=unclassified ed il resto come highway=secondary?
>

La classificazione come strada provinciale non implica una classificazione
in OSM. Questa va fatta, come hai già intuito, in base alle caratteristiche
della strada. Personalmente ho mappato strade provinciali come primary,
secondary, tertiary, unclassified e anche track.

Nella wiki inoltre non è scritto che strada provinciale implica secondary,
è scritto che secondary sono "*Strade di importanza regionale e provinciale*.
Collegano tra loro i principali comuni di una regione. Sono normalmente
classificate come SP (Strade provinciali) ma esistono eccezioni".

Ciao,

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

Re: [OSM-talk-fr] Stations service rue de Rivoli

[Francois Gouget]

On Wed, 30 Aug 2017, Frédéric Rodrigo wrote:

> J'ai exclus les points avec ces coordonnées.
> Ça sera pris en compte avec les prochaines mise à jour code d'Osmose.

Ce qui est bizarre c'est qu'à l'heure actuelle la station essence qui 
est sur le dessus de la pile rue de Rivoli a la référence 34410006. Si 
je la recherche dans PrixCarburants_annuel_2017.xml je trouve :


  Route de Valras Plage
  Srignan

Or les coordonnées du fichier, (43.2827033, 3.2802886) pointent sur la 
rue Rouget de l'Isle ***à Sérignan***. Les coordonnées ne sont donc 
probablement pas tout à fait correctes puisqu'elles ne correspondent pas 
à la route de Valras Plage et que je ne vois pas de station essence à 
proximité. Mais si Osmose place le point dans Paris ce n'est pas à 
cause de ces coordonnées.

Est-ce qu'Osmose ignore complètement les coordonnées GPS du fichier et 
fait sa propre géolocalisation à partir de l'adresse ? Car effectivement 
OpenStreetMap ne trouve pas la route de Valras Plage. Du coup on se 
retrouverait avec des coordonnées par défaut qui seraient rue de Rivoli ?

Mais faut-il vraiment ignorer les coordonnées GPS du fichier ?

Même si le géocodage du fichier n'est pas très bon, refaire le notre ne 
donnera pas forcément de meilleurs résultats :
* Les adresses sont souvent incomplètes. Par exemple il leur manque 
  souvent le numéro de rue (même pour des vraies rues).
* Si je ne me trompe OpenStreetMap n'a de toute façon souvent pas le 
  numéro de rue.
* Et il manque encore des adresses dans OpenStreetMap (comme ici).


-- 
Francois Gouget   http://fgouget.free.fr/
  "Utilisateur" (nom commun) :
Mot utilisé par les informaticiens en lieu et place d'"idiot".___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] [Desiderata] HW per servizi

[Lorenzo Mastrogiacomi]

Un taginfo italiano si potrebbe rimettere in piedi?

https://lists.openstreetmap.org/pipermail/talk-it/2016-August/054810.ht
ml



Lorenzo___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Projet du mois : suppression des landuse=industrial; retail

[Frédéric Rodrigo]

Le 02/09/2017 à 17:25, marc marc a écrit :

résumé
landuse=commercial : (/!\ faux ami) zone d'affaire, tertiaire, ZAE
landuse=retail : zones commerciales (sans activité industrielle ou
ferroviraire)
landuse=industrial : zones industrielles (y compris ferroviaires hors
zones portuaires)
landuse=harbour : zones portuaires maritimes ou fluviales (y compris les
bassins)

Le 01. 09. 17 à 14:34, Christian Quest a écrit :

Corine est généré par analyse photo de moyenne résolution et il n'est
pas évident de faire le distinguo donc dans Corine c'est une valeur
mixte... qu'on n'a donc pas pu séparé lors de l'import.

cette analyse et géré à quelle niveau ? osmfr, france ou europe ?
Il serrait peut-être utile de remonter les correctifs à cet étage

du coup pour un projet du mois, ne serrait-il pas plus efficace
d'avoir une assistance osmose :
si une zone landuse="valeur1;valeur2" ne contient que des batiments
d'un des 2 types, proposer le changement vers ce type

En m'eme temps on a déjà tellement de conseil d'osmose qu'on
n'utilise pas assez.

C'est pas faut. Osmose le fait déjà:
http://osmose.openstreetmap.fr/fr/map/#zoom=14=44.76486=-0.72382=Mapnik=3070=1%2C2%2C3


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

Re: [OSM-talk-fr] adresses de contact spéciales

[marc marc]

Le 02. 09. 17 à 16:34, Florian_G a écrit :
> on devrait n'utiliser les addr:* que pour des adresses physiques donc 
> postales 
> et des contact:* pour les adresses de contact, 
+1 c'est aussi mon avis mais attention au faux ami
selon sa page wiki https://wiki.openstreetmap.org/wiki/Key:contact
contact n'est qu'une façon de regrouper plein de tag
pour "contacter quelqu'un".
contact:phone est ainsi exactement identique que phone

> (avec ou sans :addr:*, je ne sais pas).avec, fatalement. sinon on réinvente 
> des nouveaux tag
qui seront compliqué à utiliser niveau applicatif
ceci dit on pourrait aussi tout simplement mettre
les tag "spécial" pour un poi, directement pour un poi
un peu de la même manière qu'on peux mettre un numéro de téléphone
sur un bâtiment pour le numéro général, puis un numéro différent
sur un poi si le bâtiment contient plusieurs poi
le "Cedex" dans le "faux" addr:city pourrait servir à Osmose
pour ne pas remonter une erreur dans la non existence
de cette ville et pseudo-code postal
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresses de contact spéciales

[Philippe Verdy]

Le CS c'est une mode de distribution ("Circuit spécial") qui se fait hors
des tournées normales du facteur, à horaires fixes. (le CS est comme une
boite postale, mais avec livraison)

Le TSA (Tri Spécial à l'Arrivée) c'est un mode de pré-tri à l'arrivée qui
permet de garder la confidentialité du contenu et de router le courrier
vers les bons services d'une grosse entreprise (par exemple les chèques,
les TIP vers le service paiement, les réclamations vers un autre, les
commandes vers un autre, les jeux concours vers un autre). Il peut être
fait à la poste et ce combiner avec le CS. ca permet à une grosse
entreprise d'externaliser son service courier et ne pas avoir son service
de vaguemestre interne ou de faire des réexpéditions postales en perdant du
temps.


Le 2 septembre 2017 à 16:08, marc marc  a écrit :

> Si l'adresse ne rentre pas dans les champs classique,
> il y a addr:full pour y mettre tout les détails
>
> Pour les tag supplémentaires je pense qu'il faut simplifier :
> Par exemple le "faux" code postal Cedex qui sert uniquement
> à passer par un circuit de distribution postal plus fréquent.
> Sur le bâtiment addr:postcode avec le vrai code postale (mais
> ce serrait beaucoup mieux d'utiliser boundary=postal_code)
> Sur le poi, contact:add:postcode avec le cedex ou créer
> contact:add:postcode:cedex contact:add:city:cedex
> Ceci dit, mais c'est qu'un avis perso, les cedex ne servent à rien.
> C'est une usine à gaz pour gagner au maximum une demi journée.
>
> Je ne maîtrise pas assez le CS, c'est quoi en quelques mots  ?
>
> Pour les détails internes (complément, bâtiment, chez untel)
> je pense qu'on devrait d'abord faire fonctionner correctement
> l'existant avant de l'étendre
> j'ai d'ailleurs un brouillon à ce sujet à améliorer
>
> Le 02. 09. 17 à 06:37, Philippe Verdy a écrit :
> > Pour une trésorerie publique, l'adresse de contact a:
> > - un numéro et une rue (addr:housenumber=* et addr:street=*)
> > - un complément d'adresse (deuxième ligne d'adresse)
> > - un numéro "CS " dans la troisième ligne (???)
> > - un code postal Cedex (addr:postcode=*) et la ville aussi en Cedex
> > (addr:city=Xxxx Cedex) pour la 4e ligne)
> >
> > Plusieurs questions:
> > - les code postaux cedex ne posent pas de problème dans addr:postcode=*
> > il me semble, mais ne correspondent pas à la rue indiquée en
> addr:street=*
> > - "addr:city=Xxxx Cedex" n'est pas une ville mais c'est le libellé
> > correct pour l'adresse postale, et la validation du géocodage d'une rue
> > avec cette "ville" pourrait échouer en validation avec un outil QA
> > - je n'ai pas su où mettre le CS, et j'ai utilisé faute de mieux
> > "addr:zipcode=CS " (donc en plus du "addr:postcode=* contenant le
> > code postal à 5 chiffres du Cedex.
> > - je ne sais pas où mettre le complément d'adresse (seconde ligne
> > d'adresse) quand il y en a un!
> >
> > Il manque donc des éléments dans addr:* (qui ne manque pourtant pas
> > d'autres champs comme "village", "ward", "governorate", "wilaya",
> > "state", "province", "region"... et même "hamlet" et "locality", et
> > d'autres éléments pour la Pologne).
> >
> > Peut-on avoir des champs en plus (éventuellement spécifiques à la
> > France) comme:
> >
> > - addr:city:postal=Nom-de-Ville Cedex (en plus de addr:city=Nom-de-Ville)
> > - addr:FR:deliverycode=CS  (???)
> > - addr:complement=Complément d'adresse générique (bâtiment, porte,
> > escalier, numéro de salle/chambre/appartement, nom de service...) ou des
> > champs spécifiques en plus comme:
> >
> > - addr:for=A l'attention d'Untel
> > - addr:at=Chez Untel
> > - addr:building=numéro, référence ou nom du batiment
> > - addr:door=numéro de porte
> > - addr:flat=numéro d'appartement
> > - addr:room=numéro de chambre ou salle
> > - addr:elevator=numéro d'ascenceur
> > - addr:steps=numéro d'escalier
> > - addr:floor=numéro d'étage ou nom ou abréviation comme: RDC, entresol,
> > niveau -2
> > - addr:zone= numéro de zone ou de secteur (concerne les très grandes
> > propriétés ou copropriétés) contenant une série de bâtiments avec des
> > rues et lieux-dits internes (aux USA par exemple pour les communautés
> > non organisées en collectivités publiques, ou certains ranches, ou des
> > parcs industriels et commerciaux comme la Défense où les rues
> > officielles sont cachées en sous-terrains et on circule entre les
> > niveaux pour trouver un batiment par son nom). En principe pas
> > nécessaire pour le courrier (un numéro ou nom de building suffit), mais
> > utile pour un contact sur place et rejoindre une rendez-vous !
> >
> > Note: la question ne concerne pas les noeuds d'adresse (de la BANO) mais
> > les adresses des POIs (autres noeuds ou polygones).
> >
> > Certains de ces champs seront utiles plutôt comme "contact:=*"
> > que "addr:=*"
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> 

Re: [OSM-talk-fr] Rendu FR: correction premiers zooms...

[Christian Quest]

Le 02/09/2017 à 15:00, marc marc a écrit :

Le 02. 09. 17 à 09:34, Christian Quest a écrit :

corrigé et tuiles recalculées. C'est quand même mieux !

+1

est-ce tu prévois une maj avec les autres améliorations
qui ont eu lieu sur la version mondiale ?
j'ignore sur le fork rend ce genre de fusion facile ou non.


Le fork est tellement ancien que c'est bien compliqué de reprendre des 
améliorations...



est-ce possible de soumettre d'autres améliorations ?


Oui, bien sûr, ensuite c'est en fonction de mon temps dispo que je m'y 
met, souvent en groupant car il faut un peu de tmeps pour se remettre 
dans le bain ;)



je pense par exemple à la prise en compte du nombre de bande
d'une rue pour les zooms élevé
en première approximation, une rue avec lanes=3 devrait
apparaître 3x plus large qu'une rue avec lanes=1


Oh, ça... j'ai déjà essayé et c'est affreux sur les raccords. Il suffit 
de voir ce que ça donne dans JOSM avec le style qui montre la largeur 
des voies.


Il faudrait dessiner en trapèze les zone où le nombre de voies change et 
je n'ai pas trouvé de moyen simple pour faire ça.


Par contre, d'autres choses pourraient devenir visibles: ligne continue 
ou pas, voire absente par exemple mais je pense qu'on a des trucs bien 
plus prioritaires à rendre visibles avant ça, non ?


--
Christian Quest - OpenStreetMap France


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

Re: [Talk-it] canalina che attraversa strada forestale

[Volker Schmidt]

"ford" = guado non lo è secondo me (vedi
https://en.wikipedia.org/wiki/Ford_(crossing)
)

Siccome non è un ostacolo per il traffico né pedonale né veicolare, non
vedo la necessità di taggarlo. L'unica cosa che farei è di collegare il
ruscello e la strada con un nodo comune per indicare che sono sullo stesso
livello e che non è stato dimenticato un ponte.
Ci sono tanti di questi "incroci" in OSM taggati nel modo che descrivo.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] canalina che attraversa strada forestale

[Volker Schmidt]

Io non lo mapperei del tutto. Un semplice incrocio fra ruscello e stradina
con un nodo in comune.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2017-09-02 13:10 GMT+02:00 demon.box :

> ciao, come mappo questo ruscelletto (che porta acqua tutto l'anno) e che
> attraversa la strada forestale dentro la classica canalina di scolo?
>
>  >
>
>
> non è   ford=yes
> e tunnel=culvert   nemmeno
>
> idee?
>
> grazie
>
> --enrico
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Relation zu Poly-File aus PBF

[Jochen Topf]

On Sat, Sep 02, 2017 at 12:44:22PM +0200, dktue wrote:
> ich möchte gerne kleine Regionen aus einer automatisch aktualisierten
> planet-PBF-Datei ausschneiden, aber vor dem schneiden gerne die zum
> Schneiden verwendenten .poly-Dateien aktualisieren.
> 
> Am besten wäre es, wenn ich hierzu anhand der Relation-ID diese aus der
> planet-PBF-Datei direkt extrahieren könnte. Allerdings kenne ich hierfür nur
> dieses Pearl-Script [1], welches nur mit XML-Dateien umgehen kann -- für
> Planet ist es keine Option, mit XML zu arbeiten.
> 
> Kennst jemand ein Werkzeug (oder eine Werkzeug-Kette), dass mir aus einer
> lokalen planet-PBF-Datei anhand der Relation-ID ein Poly-File schreibt, mit
> dem ich dann (mit Hilfe von osmconvert) die Regionen ausschneide?

Du kannst das mit Osmium (http://osmcode.org/osmium-tool) machen. Erster
Schritt ist mit etwas wie

  osmium getid planet.osm.pbf -r 1234 -o rel.osm.pbf

die Relation rausholen, die als Grenze dienen soll. Dann den Extract
machen:

  osmium extract planet.osm.org -p rel.osm.pbf -o ausschnitt.osm.pbf

Eine Poly-Datei brauchste nimmer, osmium kann direkt die OSM-Datei mit
der Relation verwenden.

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

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

Re: [Talk-es] Asqueado de que Google Maps te pregunte cosas, ayuda a OpenStreetmap

[Manu El]

Muy bueno. He compartido por mis redes sociales el artículo.

Manuel.

El 1 de septiembre de 2017, 12:15, Miguel de Dios Matias <
tres.14...@gmail.com> escribió:

> Buenas gente.
>
> He hecho un pequeño articulo en mi blog personal sobre StreetComplete, la
> app para Android para ayudar a OSM.
>
> http://www.tomatesasesinos.com/2017/09/01/asqueado-de-
> que-google-maps-te-pregunte-cosas-ayuda-a-openstreetmap/
>
> Supongo que tendrá algún que otro error ortográfico, mil perdones.
>
> Si veis que falta algo o algo que mejorar en el artículo, de mil amores lo
> arreglo.
>
> Saludos.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Rendu FR: correction premiers zooms...

[Philippe Verdy]

Noter que le fond mondial par défaut a rendu les landuse plus pâles
qu'avant, certainement dans le but de faciliter la réutilisation du fond de
carte pour créer des cartes personnalisées montrant des données spécifiques.
Le fond français n'a pas cette fonction et est difficilement réutilisable :
il vise à produire une carte affichée seule sans couche superposée.

On peut cependant toujours utiliser un filtre modifiant la courbe de
réponse en luminosité (un arc et non un segment  connectant les luminosités
0% et 100%), mais pour un meilleure rendu de ce filtre, il doit d'abord
convertir les couleurs RGB en HSL puis appliquer la transformée sur cette
composante L avant de remettre la couleur en RGB. Sinon il y aura des
problèmes d'artefact possible sur le rendu du texte avec le lissage des
courbes et diagonales faisant voir des liserés multicolores désagréables et
peu lisibles si on le fait avec un simple filtre RGB et la même courbe de
réponse sur chaque composante RGB, qui alors ne préserve pas correctement
la colorimétrie et la saturation).

Mais il doit être possible d'affiner le rendu français pour qu'un simple
filtre RGB puisse garder tout de même les libellés lisibles (garder leur
contraste, donc pas un simple filtre "alpha" de transparence qui rend tout
pâle, même le contraste noir sur blanc qui deviendrait gris sur blanc pas
très lisible, même si cela a aussi le même effet d'atténuer le fond en
faveur d'une couche surajoutée qui n'a alors pas besoin d'avoir un fond
blanc semitransparent, mais juste un fond totalement transparent préservant
la qualité de rendu et la lisibilité du fond de carte, pour cela il faut
évidemment que la couche surajoutée détoure correctement ce qu'elle affiche
avec des bordures locales contrastées ou des ombrages locaux
semi-transparents, mais pas de semi-transparence partout !...)

Le 2 septembre 2017 à 15:00, marc marc  a écrit :

> Le 02. 09. 17 à 09:34, Christian Quest a écrit :
> > corrigé et tuiles recalculées. C'est quand même mieux !
>
> +1
>
> est-ce tu prévois une maj avec les autres améliorations
> qui ont eu lieu sur la version mondiale ?
> j'ignore sur le fork rend ce genre de fusion facile ou non.
>
> est-ce possible de soumettre d'autres améliorations ?
> je pense par exemple à la prise en compte du nombre de bande
> d'une rue pour les zooms élevé
> en première approximation, une rue avec lanes=3 devrait
> apparaître 3x plus large qu'une rue avec lanes=1
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] canalina che attraversa strada forestale

[demon.box]

...nel frattempo mi è venuto in mente, per il solo tratto del canale di
scolo:

waterway=drain
layer=-1

potrebbe starci...



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[Talk-it] Importanza strada provinciale.

[vrmap]

Nella mia zona c'è una strada provinciale che collega due località poste in
due Comuni diversi denominata SP14. 
Nella pagina wiki è riportato che per questa tipologia di strade va mapapta
come highway=secondary. 
La parte centrale di questa strada provinciale, sviluppandosi in quota, non
è pavimentata e risulta molto meno frequentata dalle autovetture rispetto
alla sua parte iniziale e finale. 
In questi casi, secondo voi è giusto mappare tutto il tracciato come
higway=secondary oppure, essendo la parte centrale non pavimentata/meno
frequentata/meno importante, mappare la parte centrale con
highway=unclassified ed il resto come highway=secondary?  



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk-fr] Projet du mois : suppression des landuse=industrial; retail

[marc marc]

Le 01. 09. 17 à 19:24, Jérôme Amagat a écrit :
> Sur l'import, on peut voir : 
> https://wiki.openstreetmap.org/wiki/Corine_Land_Cover
Oups j'ai raté ton lien

proposition pour le 1.2.2 landuse=transport qui pourra toujours
par la suite être raffinée en landuse=railway ou landuse=highway
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois : suppression des landuse=industrial; retail

[marc marc]

résumé
landuse=commercial : (/!\ faux ami) zone d'affaire, tertiaire, ZAE
landuse=retail : zones commerciales (sans activité industrielle ou 
ferroviraire)
landuse=industrial : zones industrielles (y compris ferroviaires hors 
zones portuaires)
landuse=harbour : zones portuaires maritimes ou fluviales (y compris les 
bassins)

Le 01. 09. 17 à 14:34, Christian Quest a écrit :
> Corine est généré par analyse photo de moyenne résolution et il n'est 
> pas évident de faire le distinguo donc dans Corine c'est une valeur 
> mixte... qu'on n'a donc pas pu séparé lors de l'import.
cette analyse et géré à quelle niveau ? osmfr, france ou europe ?
Il serrait peut-être utile de remonter les correctifs à cet étage

du coup pour un projet du mois, ne serrait-il pas plus efficace
d'avoir une assistance osmose :
si une zone landuse="valeur1;valeur2" ne contient que des batiments
d'un des 2 types, proposer le changement vers ce type

En m'eme temps on a déjà tellement de conseil d'osmose qu'on
n'utilise pas assez.

Pas convaincu non plus de l'utilité des landuse vu le manque
de structure des données.
Faire une statistique par exemple entre primaire, secondaire et 
terciaire, c'est impossible sauf à se farcir un classement
à la main des très nombreuses valeurs utilisée.
il aurait fallu un système a plusieurs niveau genre
primaire -> culture -> vigne
Une idée pour François quand il s’ennuiera :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] a sample panoramic aerial image for 3D mapping made with the new DJI Spark quad-copter

[Andy Mabbett]

On 1 September 2017 at 14:37, Oleksiy Muzalyev
 wrote:

> I received today my new DJI Spark quad-copter and made a panoramic aerial
> image with it:

Impressive pic.

Curious about the drone, I found this review:

https://www.youtube.com/watch?v=_eYGih4FI8c

and now I want one!

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

[Talk-it] Fwd: Relazioni Wikimania 2017

[Federico Leva (Nemo)]

 Messaggio inoltrato 
Oggetto:[wikimedia-it] Relazioni Wikimania 2017
Data:   Fri, 1 Sep 2017 18:29:08 +0200
Mittente:   Saverio Giulio Malatesta

Cari tutti,
come da cronoprogramma sono disponibili le relazioni di coloro che hanno 
partecipato a Wikimania 2017: alcune andranno ulteriormente dettagliate 
(Orbilius, Archeolucia, Ruislip: ping!), ma da tutte emergono spunti di 
interesse e di possibile discussione. Vi invitiamo per questo a 
leggerle, postarle nei luoghi di discussione delle comunità di 
riferimento, oltre a fare domande e avanzare le vostre osservazioni.


Trovate le relazioni qui > https://wiki.wikimedia.it/wiki/Wikimania_2017

Grazie ancora ai partecipanti, e a chiunque vorrà intervenire :-)


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

Re: [OSM-talk-fr] adresses de contact spéciales

[Florian_G]

Hello,

Le 02/09/2017 à 06:42, Philippe Verdy a écrit :
> On peut citer aussi d'autres champs spéciaux similaires:
> - boites postales (BP numéro) à traiter comme (CS numéro) et (TSA numéro)
> - Autorisation (T numéro) pour l'envoi sans affranchissement.
>
>
> Le 2 septembre 2017 à 06:37, Philippe Verdy  > a écrit :
>
> Pour une trésorerie publique, l'adresse de contact a:
> - un numéro et une rue (addr:housenumber=* et addr:street=*)
> - un complément d'adresse (deuxième ligne d'adresse)
> - un numéro "CS " dans la troisième ligne (???)
> - un code postal Cedex (addr:postcode=*) et la ville aussi en Cedex 
> (addr:city=Xxxx Cedex) pour la 4e ligne)
>
> […]
>
> Il manque donc des éléments dans addr:* (qui ne manque pourtant pas 
> d'autres champs comme "village", "ward", "governorate", "wilaya", "state", 
> "province", "region"... et même "hamlet" et "locality", et d'autres éléments 
> pour la Pologne).
>
> Peut-on avoir des champs en plus (éventuellement spécifiques à la France) 
> comme:
>
Ce n'est pas utile : addr:full fait le travail car conçu pour traiter des cas 
non prévus.

Cependant, pour moi, une adresse postale (= contact) n'est pas une adresse 
physique. Une trésorerie (ou une agence bancaire, etc.) a donc 2 adresses : 
celle où tu te rends et celle où tu envoies le courrier. Vu l'historique, tout 
le monde les utilise mais il faut bien se dire que les codes postaux ne 
représentent qu'une nomenclature interne d'une entreprise aujourd'hui privée 
pour trier le courrier, en l'occurrence La Poste.

Mon sentiment est qu'on devrait n'utiliser les addr:* que pour des adresses 
physiques et des contact:* pour les adresses de contact, donc postales (avec ou 
sans :addr:*, je ne sais pas).

++

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

[Talk-is] Búinn að mála Smárana

[Jóhannes Birgir Jensson]

Hef verið að leika mér síðustu árin að prófa 3d-kortlagningu, hæð húsa, 
lögun þaks, húslitur og þaklitur.


Er núna búinn að klára Smárana. Þetta er frekar einfalt, 4-5 svæði per 
byggingu. Mætti jafnvel tvinna þetta svo inn í app þar sem hægt væri að 
viðhalda húslit eftir að búið er að mála aftur í öðrum lit - hafa árlegt 
rölt um hverfi :p


Sjá póstinn á Facebook: 
https://www.facebook.com/osmiceland/photos/a.637242849698051.1073741825.340972515991754/1457248744364120/?type=3


Tengill á F4map sem leyfir manni að hreyfa kortið í þrívídd: 
http://demo.f4map.com/#lat=64.1001467=-21.8964440=17=77.135=-59.77


--Jói / Stalfur


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Talk-de] Relation zu Poly-File aus PBF

[mmd]

Am 02.09.2017 um 12:44 schrieb dktue:

> 
> Kennst jemand ein Werkzeug (oder eine Werkzeug-Kette), dass mir aus
> einer lokalen planet-PBF-Datei anhand der Relation-ID ein Poly-File
> schreibt, mit dem ich dann (mit Hilfe von osmconvert) die Regionen
> ausschneide?
> 

Osmium-Tool sollte das alles können, siehe Beispiel mit Paris und
Frankreich:
http://osmcode.org/osmium-tool/manual.html#creating-geographic-extracts


-- 


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

Re: [OSM-talk-fr] adresses de contact spéciales

[marc marc]

Si l'adresse ne rentre pas dans les champs classique,
il y a addr:full pour y mettre tout les détails

Pour les tag supplémentaires je pense qu'il faut simplifier :
Par exemple le "faux" code postal Cedex qui sert uniquement
à passer par un circuit de distribution postal plus fréquent.
Sur le bâtiment addr:postcode avec le vrai code postale (mais
ce serrait beaucoup mieux d'utiliser boundary=postal_code)
Sur le poi, contact:add:postcode avec le cedex ou créer
contact:add:postcode:cedex contact:add:city:cedex
Ceci dit, mais c'est qu'un avis perso, les cedex ne servent à rien.
C'est une usine à gaz pour gagner au maximum une demi journée.

Je ne maîtrise pas assez le CS, c'est quoi en quelques mots  ?

Pour les détails internes (complément, bâtiment, chez untel)
je pense qu'on devrait d'abord faire fonctionner correctement
l'existant avant de l'étendre
j'ai d'ailleurs un brouillon à ce sujet à améliorer

Le 02. 09. 17 à 06:37, Philippe Verdy a écrit :
> Pour une trésorerie publique, l'adresse de contact a:
> - un numéro et une rue (addr:housenumber=* et addr:street=*)
> - un complément d'adresse (deuxième ligne d'adresse)
> - un numéro "CS " dans la troisième ligne (???)
> - un code postal Cedex (addr:postcode=*) et la ville aussi en Cedex 
> (addr:city=Xxxx Cedex) pour la 4e ligne)
> 
> Plusieurs questions:
> - les code postaux cedex ne posent pas de problème dans addr:postcode=* 
> il me semble, mais ne correspondent pas à la rue indiquée en addr:street=*
> - "addr:city=Xxxx Cedex" n'est pas une ville mais c'est le libellé 
> correct pour l'adresse postale, et la validation du géocodage d'une rue 
> avec cette "ville" pourrait échouer en validation avec un outil QA
> - je n'ai pas su où mettre le CS, et j'ai utilisé faute de mieux 
> "addr:zipcode=CS " (donc en plus du "addr:postcode=* contenant le 
> code postal à 5 chiffres du Cedex.
> - je ne sais pas où mettre le complément d'adresse (seconde ligne 
> d'adresse) quand il y en a un!
> 
> Il manque donc des éléments dans addr:* (qui ne manque pourtant pas 
> d'autres champs comme "village", "ward", "governorate", "wilaya", 
> "state", "province", "region"... et même "hamlet" et "locality", et 
> d'autres éléments pour la Pologne).
> 
> Peut-on avoir des champs en plus (éventuellement spécifiques à la 
> France) comme:
> 
> - addr:city:postal=Nom-de-Ville Cedex (en plus de addr:city=Nom-de-Ville)
> - addr:FR:deliverycode=CS  (???)
> - addr:complement=Complément d'adresse générique (bâtiment, porte, 
> escalier, numéro de salle/chambre/appartement, nom de service...) ou des 
> champs spécifiques en plus comme:
> 
> - addr:for=A l'attention d'Untel
> - addr:at=Chez Untel
> - addr:building=numéro, référence ou nom du batiment
> - addr:door=numéro de porte
> - addr:flat=numéro d'appartement
> - addr:room=numéro de chambre ou salle
> - addr:elevator=numéro d'ascenceur
> - addr:steps=numéro d'escalier
> - addr:floor=numéro d'étage ou nom ou abréviation comme: RDC, entresol, 
> niveau -2
> - addr:zone= numéro de zone ou de secteur (concerne les très grandes 
> propriétés ou copropriétés) contenant une série de bâtiments avec des 
> rues et lieux-dits internes (aux USA par exemple pour les communautés 
> non organisées en collectivités publiques, ou certains ranches, ou des 
> parcs industriels et commerciaux comme la Défense où les rues 
> officielles sont cachées en sous-terrains et on circule entre les 
> niveaux pour trouver un batiment par son nom). En principe pas 
> nécessaire pour le courrier (un numéro ou nom de building suffit), mais 
> utile pour un contact sur place et rejoindre une rendez-vous !
> 
> Note: la question ne concerne pas les noeuds d'adresse (de la BANO) mais 
> les adresses des POIs (autres noeuds ou polygones).
> 
> Certains de ces champs seront utiles plutôt comme "contact:=*" 
> que "addr:=*"
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [Talk-it] canalina che attraversa strada forestale

[girarsi_liste]

Il 02/09/2017 13:10, demon.box ha scritto:
> ciao, come mappo questo ruscelletto (che porta acqua tutto l'anno) e che
> attraversa la strada forestale dentro la classica canalina di scolo?
> 
>  
> 
> 
> non è   ford=yes
> e tunnel=culvert   nemmeno
> 
> idee?

Volendo sarebbe un waterway=drain, però è un pò piccola per esserla,
l'unica cosa che ho trovato si avvicini in inglese è questa:

https://en.wikipedia.org/wiki/Street_gutter

Però non trovo la corrispondente versione trasversale per strade forestali.

Nemmeno su wikipedia italiana, dove trovo solo la versione italiana di
quella inglese, cioè cunetta, ma mi pare diversa.

Lascerei ford=yes, e insieme un tag description, diversamente non so se
si può inventare un nuovo valore waterway, o ford, non ne ho idea,
sinceramente fin'ora ho sempre messo ford=yes.



-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [Talk-de] Relation zu Poly-File aus PBF

[dktue]

Hallo Frederik,

danke für die gute Idee mit dem Download der Relation von Overpass. Ich 
möchte die Daten direkt aus der PBF-Datei holen die ich auch schneide um 
sicherzustellen, dass die Grenzen kongruent sind. Aber ich vermute, ich 
kann das einfach mit osmfilter machen und dann eventuell durch osm2poly 
laufen lassen.


Viele Grüße
dktue

Am 02.09.2017 um 15:40 schrieb Frederik Ramm:

Hi,

On 02.09.2017 12:44, dktue wrote:

Am besten wäre es, wenn ich hierzu anhand der Relation-ID diese aus der
planet-PBF-Datei direkt extrahieren könnte. Allerdings kenne ich hierfür
nur dieses Pearl-Script [1], welches nur mit XML-Dateien umgehen kann --
für Planet ist es keine Option, mit XML zu arbeiten.

Du kannst das OSM-File von Overpass holen oder mit

wget -O meinfile.osm
http://api.openstreetmap.org/api/0.6/relation/1234deinenummerhier4321/full

runterladen und dann in osm2poly stopfen. Du könntest auch die Relation
in JOSM runterladen ("download object from OSM") und dann, wenn Du das
poly-File-Plugin hast, direkt als .poly abspeichern.

Bye
Frederik




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

Re: [Talk-de] Relation zu Poly-File aus PBF

[Frederik Ramm]

Hi,

On 02.09.2017 12:44, dktue wrote:
> Am besten wäre es, wenn ich hierzu anhand der Relation-ID diese aus der 
> planet-PBF-Datei direkt extrahieren könnte. Allerdings kenne ich hierfür 
> nur dieses Pearl-Script [1], welches nur mit XML-Dateien umgehen kann -- 
> für Planet ist es keine Option, mit XML zu arbeiten.

Du kannst das OSM-File von Overpass holen oder mit

wget -O meinfile.osm
http://api.openstreetmap.org/api/0.6/relation/1234deinenummerhier4321/full

runterladen und dann in osm2poly stopfen. Du könntest auch die Relation
in JOSM runterladen ("download object from OSM") und dann, wenn Du das
poly-File-Plugin hast, direkt als .poly abspeichern.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk-fr] Rendu FR: correction premiers zooms...

[marc marc]

Le 02. 09. 17 à 09:34, Christian Quest a écrit :
> corrigé et tuiles recalculées. C'est quand même mieux !

+1

est-ce tu prévois une maj avec les autres améliorations
qui ont eu lieu sur la version mondiale ?
j'ignore sur le fork rend ce genre de fusion facile ou non.

est-ce possible de soumettre d'autres améliorations ?
je pense par exemple à la prise en compte du nombre de bande
d'une rue pour les zooms élevé
en première approximation, une rue avec lanes=3 devrait
apparaître 3x plus large qu'une rue avec lanes=1
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Relation zu Poly-File aus PBF

[Walter Nordmann]

Hi

Am 02.09.2017 um 12:44 schrieb dktue:

Hallo,

ich möchte gerne kleine Regionen aus einer automatisch aktualisierten 
planet-PBF-Datei ausschneiden, aber vor dem schneiden gerne die zum 
Schneiden verwendenten .poly-Dateien aktualisieren.


Wenn sich das Gebiet durch eine Admingrenze (evtl mit Buffer) 
beschreiben lässt, versuche mal


https://wambachers-osm.website/boundaries/

- oAuth erlauben
- Grenze auswählen
- poly oder bpoly
- bei bpoly einen Buffer um das Gebiet legen
- export

Gruss
walter, aka wambacher

ps: der Exporter wird derzeit neu geschrieben, aber so geht es auch.

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

[Talk-it] canalina che attraversa strada forestale

[demon.box]

ciao, come mappo questo ruscelletto (che porta acqua tutto l'anno) e che
attraversa la strada forestale dentro la classica canalina di scolo?

 


non è   ford=yes
e tunnel=culvert   nemmeno

idee?

grazie

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[Talk-it] canalina che attraversa strada forestale

[demon.box]

ciao, mi ritrovo questo ruscelletto che porta acqua tutto l'anno e che
attraversa la strada forestale passando dentro la classica canalina di
scolo:

 

come lo taggo?

ford=yes   non è
tunnel=culvert nemmeno...

idee?

grazie

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[Talk-de] Relation zu Poly-File aus PBF

[dktue]

Hallo,

ich möchte gerne kleine Regionen aus einer automatisch aktualisierten 
planet-PBF-Datei ausschneiden, aber vor dem schneiden gerne die zum 
Schneiden verwendenten .poly-Dateien aktualisieren.


Am besten wäre es, wenn ich hierzu anhand der Relation-ID diese aus der 
planet-PBF-Datei direkt extrahieren könnte. Allerdings kenne ich hierfür 
nur dieses Pearl-Script [1], welches nur mit XML-Dateien umgehen kann -- 
für Planet ist es keine Option, mit XML zu arbeiten.


Kennst jemand ein Werkzeug (oder eine Werkzeug-Kette), dass mir aus 
einer lokalen planet-PBF-Datei anhand der Relation-ID ein Poly-File 
schreibt, mit dem ich dann (mit Hilfe von osmconvert) die Regionen 
ausschneide?


Viele Grüße
dktue

[1] 
http://svn.openstreetmap.org/applications/utils/osm-extract/polygons/osm2poly.pl


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

Re: [OSM-talk] a sample panoramic aerial image for 3D mapping made with the new DJI Spark quad-copter

[Komяpa]

We're using DJI Mavic ($1000), Pix4D Capture application and Pix4D
($300/mo) to get orthorectified imagery in Belarus. It takes 1 battery, 20
minutes of flight time and several hours processing to get 1x1 km chunk in
6 cm/px.

Sample:
https://cloud.pix4d.com/pro/project/169316?shareToken=9fda4c2a6fc64b938886d3f4fa477692


DSM and 3D is also generated.

We upload it to OpenAerialMap. There are some issues in their pipeline that
make imagery not very crisp:
https://github.com/hotosm/oam-dynamic-tiler/issues/49


пт, 1 сент. 2017 г. в 18:42, Oleksiy Muzalyev :

> On 9/1/2017 5:12 PM, Martin Koppenhoefer wrote:
>
>
>
> 2017-09-01 16:24 GMT+02:00 Oleksiy Muzalyev :
>
>>
>> But the advantage is that it weighs only 300 grams, very portable, and it
>> is ready to fly almost instantly as folding propellers are fixed
>> permanently, and smart-phone connects to the remote control via WiFi, no
>> cables are necessary.
>>
>
>
> did you try how high/far you can get before loosing the wifi connection?
>
> Cheers,
> Martin
>
> Hello Martin and James,
>
> In this case was talking about Wi-Fi connection between smart-phone where
> runs DJI Go 4 app and the remote control radio, they remain close to one
> another all the time. But certainly the flight range of Spark is not as
> great as the one of the Phantom.
>
> There is a list of compatible smart-phones for the Spark at the very
> bottom of this page: http://www.dji.com/spark/info#specs . I read at the
> DJI forum that if one uses such a smart-phone the range is better.
>
> I flew Spark maximum about 700 meters away and 150 (legal limit for the
> region) meters high. The video & control signals was present all the time,
> though my old smart-phone is not in the list. I ordered already a
> compatible one.
>
> For me this range is OK. The best aerial photos are made from the altitude
> of 70 - 100 meters anyway, and besides in accordance with the regulations
> it is allowed to fly only LoS (line-of-sight) anyway (unless there is a
> special license).
> The Spark remote controller has got folding outside antennas, so the range
> of several hundred meters, or I would guess up to 1 - 1.2 km, is probably
> due to these antennas. The range of the Phantom is more than 2 km.
>
> Best regards,
>
> Oleksiy
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-fr] Rendu FR: correction premiers zooms...

[Christian Quest]

Il y avait un bug dans le rendu FR depuis quelques temps sur les premiers
niveaux de zoom, les libellés de pays, région, continents avaient disparu.

Tout ça à cause d'un "coalesce" qui avait sauté dans une requête
postgres... corrigé et tuiles recalculées. C'est quand même mieux !

http://tile.openstreetmap.fr/?zoom=3=45=0

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

Re: [Talk-it] Sala giochi

[dgitto]

Grazie



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-cz] Názvy vodních nádrží a water=reservoir

[Michal Poupa]

Hodně přehrad bylo a možná ještě je zadáno jako "využití krajiny"  
landuse reservoir
a ne jako přehrada 

natural=water + water=reservoir.

Tímto způsobem je zadána bohužel i spousta rybníků - je možno to nějak hromadně 
převést na ten nový způsob? Tedy na 

natural=water + water=pond

Michal

1. 9. 2017 v 21:27, Jan Dudík :

> ještě jsem se setkal někde s v. d. (vodní dílo)
> 
> JAnD
> 
> ---
> Dne 31. srpna 2017 10:57 Michal Poupa  napsal(a):
>> nejlepší název má toto jen "v.n." :-)
>> 
>> 
>> https://www.openstreetmap.org/search?query=v.%20n.%20#map=17/49.09062/16.70460
>> 
>> Dne 31. srpna 2017 9:48 Jan Martinec  napsal(a):
>> 
>>> 
>>> 
>>> Dne 31. 8. 2017 9:06 napsal uživatel "Pavel Machek" :
>>> Ahoj!
>>> 
>>> > Tech v. n. je tam hodně ale podle mne není problém dát robotem to na 
>>> > Vodní nádrž stačí jednoduchý filter
>>> >
>>> > water=reservoir a hledat všechny kombinace skratky v názvu  bez mezer s z 
>>> > mezerami a malá velká písmena. Takže nevidím jediný problém proč by 
>>> > robotem nešla odstranit zkratka.
>>> >
>>> 
>>> Jo sorry, zkratku bych se asi odstranit nebal. Tedy
>>> 
>>> "v. n." -> "vodni nadrz"
>>> 
>>> za me dobry
>>> 
>>> "v. n." -> ""
>>> 
>>> (z uvahy ze je to nepodstatny protoze je to videt z tagu) bych
>>> nedelal.
>>> Jsem pro, ale možná by stálo za to přidat ten název bez zkratky do 
>>> sorting_name, nebo to už dnešní vyhledávače umí nativně?
>>> 
>>> Zdar,
>>> HPM 
>>> Pavel
>>> --
>>> (english) http://www.livejournal.com/~pavelmachek
>>> (cesky, pictures) 
>>> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>>> 
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-cz
>>> 
>>> 
>>> 
>>> ___
>>> Talk-cz mailing list
>>> Talk-cz@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-cz
>>> 
>> 
>> 
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> 
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

hebdoOSM Nº 371 2017-08-22-2017-08-28

[weeklyteam]

Bonjour,

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

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

Bonne lecture !

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

hebdoOSM Nº 371 2017-08-22-2017-08-28

[weeklyteam]

Bonjour,

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

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

Bonne lecture !

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

hebdoOSM Nº 371 2017-08-22-2017-08-28

[weeklyteam]

Bonjour,

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

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

Bonne lecture !

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