date:20180404

sent from a phone

> On 3. Apr 2018, at 07:47, Federico Cortese  wrote:
> 
> Secondo me sono comunque due segnali autonomi. Il limite di velocità parte 
> dal segnale fino al primo incrocio, quindi maxspeed=30 (non max_speed) + 
> source:maxspeed=sign li puoi aggiungere al tratto di strada. Il dosso poi lo 
> mappi sul nodo.

sicuro sulla fine del limite? In Germania un limite di velocità che viene dato 
insieme ad un altro cartello di avviso (per esempio 2 curve strette, oppure 
scuola), vale fin che hai superato il pericolo.

Comunque sono d’accordo con la mappatura a prescindere, mapperei l’ostacolo e 
il limite dove sono, senza necessariamente legare le due.

Ciao, Martin 

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

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

Les capteurs supplémentaires peuvent servir, mais même une puce GPS sans
capteur annexe pourra faire de l'extrapolation et du lissage... les Garmin
des années 2005 faisaient déjà ça.

C'est pour ça que les données NMEA supplémentaires (nombre de sat, DOP,
etc) permettent de savoir si le calcul se base bien sur les signaux reçus
et pas sur de l'extrapolation.

Avec des accéléromètres, l'extrapolation peut être améliorée, car on a au
moins des infos complémentaires pour le calcul.

Donc le mieux pour une position précise ce sont (de mon point de vue):
1) des signaux nombreux et de qualité (DOP faible)... et une correction
différentielle (RTK)
2) des signaux nombreux et de qualité (DOP faible)
3) peu de signaux mais compensés correctement lorsqu'on est en mouvement et
pour de courte durées par des accéléromètres
4) peu de signaux et rien de plus... donc DOP élevée
5) peu de signaux et une extrapolation trompeuse... donc DOP plus vraiment
fiable


Le 4 avril 2018 à 21:55, Stéphane Péneau  a
écrit :

> Pour la trace jaune, j'ai découvert en remontant les informations, que le
> récepteur de cette tablette Nexus 9 semble intégrer des capteurs
> supplémentaires, accéléromètre, gyroscope, etc... Je me demande à quoi ça
> ressemblerait s'ils n'étaient pas là.
> https://www.broadcom.com/products/wireless/gnss-gps-socs/bcm4752
>
>
> Plus généralement, et de ce que j'ai compris, c'est donc à prendre avec
> des pincettes, tous les récepteurs font du filtrage. Le navspark a un mode
> automatique, un mode voiture, piéton, etc..
>
> En tout cas, lorsqu’avec un récepteur me fournissant du RAW je tente un
> calcul dans RTKLIB en mode "single", ce n'est pas beau à voir.
>
> Oui, le DOP indique bien que la réception est mauvaise pendant le passage
> sous le tunnel :
> http://www.stemani.fr/public/gnss/gnss5.JPG
>
> Stf
>
>
>
> Le 04/04/2018 à 12:40, Christian Quest a écrit :
>
> La jaune est typique d'un GPS "routier", qui fait de l'overshooting dans
> les virages... c'est à dire qui tient compte des déplacements précédents
> pour "lisser".
> C'est un phénomène qui ne date pas d'hier, il y a plus de 10 ans, ça me
> posait des problèmes pour les contrôles de vols dans les compétitions de
> parapente !
>
> Exemple: http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_
> 208577#19/47.13163/-1.50767
>
> Sur le rond point le vert ne déborde pas, par contre, le passage sous
> l'autoroute n'est pas lissé comme le jaune (et tant mieux, si on a le DOP
> indiqué).
>
> Pour moi c'est le vert qui s'en sort le mieux, correspond à des mesures
> réelles et pas extra/inter-polées... tout le bénef d'un GPS dédié et où ces
> extrapolation peuvent être en principe désactivées (ou plutôt activées à la
> demande et pas l'inverse).
>
>
>
> Le 3 avril 2018 à 18:41, Stéphane Péneau  a
> écrit :
>
>> Hello,
>>
>> Alors, qui était qui dans ce test ?
>>
>> Je rappelle les protagonistes :
>> - Smartphone Sony Xperia Ray
>> - Smartphone HTC One mini
>> - Tablette Nexus 9
>> - Tablette Nvidia Tablet Shield K1
>> - Navspark GL.
>>
>> Et les résultats :
>> http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577
>>
>> On peut facilement éliminer la trace bleue (Xperia Ray), la orange (HTC
>> One mini), ainsi que la rouge (Nvidia Shield).
>> Il nous reste la trace verte et la trace jaune.
>>
>> Je le rappelais, ce n'est pas vraiment la position absolue qui comptait
>> dans ce test, mais la façon dont les traces se décalaient en cas
>> d'obstacles alors que le déplacement reste rectiligne. Une antenne sur le
>> toit est censée mieux capter les signaux des satellites, et pouvoir plus
>> facilement discriminer les signaux ayant subi un rebond.
>> Voici quelques pistes où les traces vertes restent parallèles alors que
>> les jaunes dérivent :
>> http://www.stemani.fr/public/gnss/gnss1.jpg
>> http://www.stemani.fr/public/gnss/gnss2.jpg
>> http://www.stemani.fr/public/gnss/gnss3.jpg
>> C'est encore plus flagrant sur cette dernière capture :
>> http://www.stemani.fr/public/gnss/gnss4.jpg
>>
>> La trace jaune est la tablette Nexus 9, et la verte est bien le récepteur
>> Navspark GL avec l'antenne sur le toit.
>>
>> Si quelqu'un souhaite regarder de plus près, par exemple dans Josm, les
>> voici :
>> http://www.stemani.fr/public/gnss/test_gnss.zip
>>
>> Stéphane
>>
>>
>>
>>
>>
>> Le 28/03/2018 à 00:59, Stéphane Péneau a écrit :
>>
>>> Le 28/03/2018 à 00:10, Francois Gouget a écrit :
>>>
 J'aurais tendance à dire qu'il n'y en a pas un pour rattraper les
 autres. Mais peut-être ai-je raté les points importants ?

>>> Normalement, si tu décoches au fur et à mesure les traces qui te semble
>>> les moins bonnes pour qu'elles ne perturbent plus l'affichage, tu devrais
>>> trouver assez facilement celle qui vient de l'antenne sur le toit.
>>> J'avoue qu'avoir quelques niveaux de zooms supplémentaires, ça aide,
>>> mais umap semble limité sur ce point.
>>>
>>> Je donnerai la réponse

[OSM-talk] Maps rendering forum

2018-04-04 Per discussione Daniel Koć

Hi,

I think we need a place to discuss maps rendering using OSM data, so I
created special subforum to talk about it:

https://forum.openstreetmap.org/viewforum.php?id=100


-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO

C'est un peu plus compliqué que ça...

Cette licence ne s'applique que pour des usages de mission de service
public, de recherche, d'enseignement, ou de démonstration et évaluation
(sur des échantillons).

Pour un ré-utilisateur lambda, ces données restent payantes... car l'IGN,
Météo France et le SHOM sont les 3 opérateurs restants qui peuvent encore
percevoir des redevances de réutilisations, donc vendre des données...
parce que "la couverture des coûts liés à cette activité principale est
assurée à moins de 75 % par des recettes fiscales, des dotations ou des
subventions."

Un de ces jours il faudra vérifier ces 75% (calculés sur 3 ans) et aussi si
les tarifs de ces redevances ne sont pas exagérés, car la Loi les limite:
"Le produit total du montant de cette redevance, évalué sur une période
comptable appropriée, ne dépasse pas le montant total des coûts liés à la
collecte, à la production, à la mise à la disposition du public ou à la
diffusion de leurs informations publiques."

Bref... ça m'étonnerai que le 5 mai on entre dans une nouvelle ère sur ces
seuls bases légales.
Pour qu'il y ait un vrai changement, il faut un choix politique assumé (y
compris en interne).


Le 4 avril 2018 à 17:40, Vincent Frison  a écrit :

> En fait d'après cette page  l'IGN a
> visiblement obtenu l'an passé une dérogation pour continuer à utiliser leur
> licence actuelle pour la BD TOPO (entre autres) jusqu'au 4 mai 2018. Mais
> peut-être qu'à partir de ce moment là ils seront obligés d'utiliser une
> licence ouverte !
>
> *La « licence d’utilisation à titre gratuit
>  » de l’institut
> national géographique et forestier (IGN) est homologuée par la décision
> d'homologation
> 
>  du
> 5 mai 2017 pour le périmètre des données géographiques BD ORTHO®, BD TOPO®,
> BD PARCELLAIRE®, BD ADRESSE® et RGE ALTI®  jusqu'au 4 mai 2018.*
>
> Et au pire, même s'ils arrivent encore à repousser encore la date,
> peut-être qu'on pourrait effectivement leur demander une autorisation
> spéciale pour OSM (au moins pour les hauteurs de bâtiments).
>
> ++ Vincent.
>
>
-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-us] Save the Date: State of the Map US 2018 is in Detroit!

2018-04-04 Per discussione Ian Dees

Hi everyone!

The State of the Map US 2018 team and the OpenStreetMap US Board are
excited to announce that the next State of the Map US event will be held in
Detroit over the weekend of October 5-7.

More information can be found in our blog post:
https://www.openstreetmap.us/2018/04/announcing-sotm-us-2018-detroit/

and on our website:
https://2018.stateofthemap.us/

If you're interested in helping with the program, scholarships,
fundraising, volunteer coordination, or anything else, please let us know!
You can email us at sot...@openstreetmap.us or reply to me.

Looking forward to seeing you all in Detroit,
Ian
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-de] Flächen/Wege // Trolling in changesets

sent from a phone

> On 4. Apr 2018, at 18:23, Christian Müller  wrote:
> 
> Ok, das habe ich verstanden.  Du hast aber nicht verstanden, dass
> wir auch die neu gebildeten Flächen wiederum genauer mappen können,
> wenn wir nur genau genug hinschauen.  Und immer wieder
> ergeben sich dieselben Fragen:

ja, wobei sie vermutlich den meisten immer unwesentlicher erscheinen, je 
untergeordneter die Stellen sind.

> 
> Was ist dazwischen, sollten wir nicht eine Lücke lassen?
> Oder sollten wir die Lücke unterschlagen, weil sie unter
> gegebenen Umständen nicht relevant erscheint?

ich würde die Lücke lassen, wobei das auch Grenzen hat, z.B. mappe ich einen 
Zaun oder eine Mauer als einzige Linie, obwohl die natürlich in der Realität 
eine gewisse Dicke haben.

> 
> Vielleicht läuft auf der Waldgrenze ein Weg, der hat, bei genauer
> Betrachtung eine Fläche, also grenzt dann nicht Wald an Wiese,
> sondern Wald an Weg und Weg an Wiese, nicht?

ja, in diesem Fall würde ich 3 ways machen, einen für die Wiese, einen für den 
Weg und einen für den Waldrand. Die haben oft auch nicht genau dieselbe Form.

Du schriebst weiter oben, die geometrischen und Lagedetails seien komplett 
unwichtig, ich sehe das ganz anders, es gibt für Formen, Abweichungen, etc. 
normalerweise einen Grund, Grenzen und Flächen liegen zwar manchmal 
willkürlich, oft aber auch nicht.

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

[talk-au] Coastline mods leading to problems with other features.

2018-04-04 Per discussione Warin


Hi,

I have found a few minor problems with some coastline modifications 
performed by the microsoft team members.


Some of these I have fixed myself, others have been fixed by the authors.


However Relation: Sydney Harbour (1252425) and Relation: Brisbane Water 
National Park (5860233) are now broken ...


These are large with conflicts between sea (coastline) and fresh water 
(harbour/river).



Any 'experts' on water tagging want to fix these?


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

Re: [OSM-talk-fr] Rapprochement des adresses OSM et FANTOIR

2018-04-04 Per discussione Vincent de Château-Thierry


Bonsoir,

Le 04/04/2018 à 17:53, deuzeffe a écrit :


Est-ce qu'on peut supposer que la correction du bug concerne tout le 
territoire (ou suis-je trop pressée ;p) ?


Parce que le problème (constaté depuis plusieurs mois sans oser trop 
dire quoi que ce soit ^^) persiste (vérifié à l'instant) dans mon coin, 
par exemple ici : 
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#15/45.8138/1.1464


Si tu parles d'Aixe-sur-Vienne désolé, la commune n'est pas concernée. 
Les communes concernées sont celles où les textes de voies du cadastre 
sont parfois suffixés, souvent par le nom du hameau où elles se situent. 
Le suffixe est détecté dans les traitements de BANO pour que les 
tentatives de rapprochement entre le texte des voies d'OSM et celui des 
voies du Cadastre en fasse abstraction.


Quand j'ai indiqué la correction hier je me suis avancé. Elle était 
effective sur les P.O. pour les cas de Rainer mais sur le reste de la 
France des mécanismes de cache ont masqué cette correction dans le batch 
de cette nuit. Ce matin j'ai purgé tous les caches, logiquement la 
correction sera vraiment France entière demain (jeudi) matin.


Donc pour avancer, il faudrait que tu décrives ton problème, s'il est 
différent.


vincent

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

[Talk-cz] Syntetické názvy v cizích jazycích

2018-04-04 Per discussione Jan Martinec

Ahoj,

minulý rok jsme tu řešili, jestli je v Praze stanice metra Engel nebo Black
Bridge...tak jsme byli zase napřed ;)

Dneska začal dělat Google cosi podobného...s předvídatelnými výsledky:

https://m.facebook.com/story.php?story_fbid=10155415677386680=712386679

TL;DR: uživatelstvo je zmateno, že má najednou v navigaci jiné stanice, než
jsou kdekoli vypsané.

Zdar,
Honza Piškvor Martinec
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Tag pour "chaussées à voie centrale banalisée" ?

On va donc en rester à la L3 selon
https://wiki.openstreetmap.org/wiki/FR:Bicycle#Bandes_cyclables

oneway=no
lanes=1
cycleway=lane

Merci.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Tag pour "chaussées à voie centrale banalisée" ?

2018-04-04 Per discussione jabali

Il n'existe encore aucun consensus pour les chaussées à voie centrale
banalisée vs Pistes cyclables exclusives
Leurs aspects et réglementations varient en fonction des pays.
Le pb rempli d'ailleurs un grand nombre de pages de topics variés sur les
forums osm.org.

Une tentative de synthèse-conciliation se passe en ce moment ici

https://forum.openstreetmap.org/viewtopic.php?pid=692080#p692080

A garder sous le coude car l'approche me semble correcte.
++





--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Tag pour "chaussées à voie centrale banalisée" ?

2018-04-04 Per discussione Antoine Riche

Suivez la doc : cas L3 sur 
https://wiki.openstreetmap.org/wiki/FR:Bicycle#Bandes_cyclables. Ça a le 
mérite d'être simple et de décrire le terrain : lanes=1 indique qu'il 
n'y a qu'une voie (sous-entendu pour les véhicules à moteur) ; oneway=no 
précise qu'elle n'est pas en sens unique ; cycleway=lane dit qu'il y a 
une bande cyclable de chaque côté de la chaussée.


Shoreh : le hasard a fait que je faisais aujourd'hui du contrôle qualité 
pour le projet #CartoVeloIDF. Je suis repassé derrière toi avant de voir 
la discussion sur la liste.


Antoine.

Le 04/04/2018 à 18:10, marc marc a écrit :

Le 04. 04. 18 à 16:36, Shohreh a écrit :


Même aux Pays-Bas, il ne semble pas exister de tag simple pour un
"fietsstrook" (pl : fietsstroken); ils recommendent d'utiliser
highway= + cycleway=shared_lane :

https://wiki.openstreetmap.org/wiki/NL:Cycleway#Fietsstroken_2
https://nl.wikipedia.org/wiki/Fietsstrook

non c'est incohérent.
cycleway=shared_lane implique que la bande est partagée.
une bande réservée aux cyclistes n'est pas partagée.

  > Rue de la Minière à Buc (banlieue sud de Paris),
  > c'est simplement taggé comme ça :
  > https://s17.postimg.org/6840jnl8v/Chaucidou.rue.de.la.Miniere.Buc.OSM.png

  > Ça semble plutôt mieux, non ?
  > 1. Laisser le défaut "Oneway=no"
  > 2. Modifier "cycleway" en "both"
  > 3. Ajouter "lanes=1"
  >
https://s17.postimg.org/pv2f8xx3z/Chaucidou.rue.de.la.Miniere.Buc.OSM.suggestion.png

suggestions :)
- faire un email au lieu de 3 :)
- cycleway:left=lane+cycleway:right=lane indique qu'il y a une bande
à gauche ET une bande à droite.
La vue sat a l'air de correspondre à cela.
c'était exactement aussi le même sens que cycleway=lane existant
La situation existant était parfaitement juste.
j'aime bien quand quelqu'un demande si c'est mieux la modif
qu'il veux faire mais la fait sans attendre la réponse :)
il y a plus qu'à revenir en arrière :)
parce que cycleway=both ne veux rien dire. puisque la valeur de cycleway
est le type d'aménagement (une bande isolée ou partageée ou en sens
inverse).
sans doute voulais-tu dire cycleway:both=lane qui correspond exactement
à la description de cycleway=lane (on ne met pas de sufixe :both quand
les 2 sont identiques)

Quand à l'exemple initial d'une bande CENTRALE cela nécessiterait
un cycleway:center=lane (probablement non utilisé par les apps
mais c'est un autre débat).
J'ignore si c'est le cas pour la rue de la Miniere
la vue sat montre des voitures au centre, j'ignore s'ils sont en
infraction ou si la situation a changé ou si tu parlais d'un autre cas

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





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

2018-04-04 Per discussione Stéphane Péneau

Pour la trace jaune, j'ai découvert en remontant les informations, que 
le récepteur de cette tablette Nexus 9 semble intégrer des capteurs 
supplémentaires, accéléromètre, gyroscope, etc... Je me demande à quoi 
ça ressemblerait s'ils n'étaient pas là.

https://www.broadcom.com/products/wireless/gnss-gps-socs/bcm4752


Plus généralement, et de ce que j'ai compris, c'est donc à prendre avec 
des pincettes, tous les récepteurs font du filtrage. Le navspark a un 
mode automatique, un mode voiture, piéton, etc..


En tout cas, lorsqu’avec un récepteur me fournissant du RAW je tente un 
calcul dans RTKLIB en mode "single", ce n'est pas beau à voir.


Oui, le DOP indique bien que la réception est mauvaise pendant le 
passage sous le tunnel :

http://www.stemani.fr/public/gnss/gnss5.JPG

Stf


Le 04/04/2018 à 12:40, Christian Quest a écrit :
La jaune est typique d'un GPS "routier", qui fait de l'overshooting 
dans les virages... c'est à dire qui tient compte des déplacements 
précédents pour "lisser".
C'est un phénomène qui ne date pas d'hier, il y a plus de 10 ans, ça 
me posait des problèmes pour les contrôles de vols dans les 
compétitions de parapente !


Exemple: 
http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577#19/47.13163/-1.50767


Sur le rond point le vert ne déborde pas, par contre, le passage sous 
l'autoroute n'est pas lissé comme le jaune (et tant mieux, si on a le 
DOP indiqué).


Pour moi c'est le vert qui s'en sort le mieux, correspond à des 
mesures réelles et pas extra/inter-polées... tout le bénef d'un GPS 
dédié et où ces extrapolation peuvent être en principe désactivées (ou 
plutôt activées à la demande et pas l'inverse).




Le 3 avril 2018 à 18:41, Stéphane Péneau > a écrit :


Hello,

Alors, qui était qui dans ce test ?

Je rappelle les protagonistes :
- Smartphone Sony Xperia Ray
- Smartphone HTC One mini
- Tablette Nexus 9
- Tablette Nvidia Tablet Shield K1
- Navspark GL.

Et les résultats :
http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577


On peut facilement éliminer la trace bleue (Xperia Ray), la orange
(HTC One mini), ainsi que la rouge (Nvidia Shield).
Il nous reste la trace verte et la trace jaune.

Je le rappelais, ce n'est pas vraiment la position absolue qui
comptait dans ce test, mais la façon dont les traces se décalaient
en cas d'obstacles alors que le déplacement reste rectiligne. Une
antenne sur le toit est censée mieux capter les signaux des
satellites, et pouvoir plus facilement discriminer les signaux
ayant subi un rebond.
Voici quelques pistes où les traces vertes restent parallèles
alors que les jaunes dérivent :
http://www.stemani.fr/public/gnss/gnss1.jpg

http://www.stemani.fr/public/gnss/gnss2.jpg

http://www.stemani.fr/public/gnss/gnss3.jpg

C'est encore plus flagrant sur cette dernière capture :
http://www.stemani.fr/public/gnss/gnss4.jpg


La trace jaune est la tablette Nexus 9, et la verte est bien le
récepteur Navspark GL avec l'antenne sur le toit.

Si quelqu'un souhaite regarder de plus près, par exemple dans
Josm, les voici :
http://www.stemani.fr/public/gnss/test_gnss.zip


Stéphane





Le 28/03/2018 à 00:59, Stéphane Péneau a écrit :

Le 28/03/2018 à 00:10, Francois Gouget a écrit :

J'aurais tendance à dire qu'il n'y en a pas un pour
rattraper les
autres. Mais peut-être ai-je raté les points importants ?

Normalement, si tu décoches au fur et à mesure les traces qui
te semble les moins bonnes pour qu'elles ne perturbent plus
l'affichage, tu devrais trouver assez facilement celle qui
vient de l'antenne sur le toit.
J'avoue qu'avoir quelques niveaux de zooms supplémentaires, ça
aide, mais umap semble limité sur ce point.

Je donnerai la réponse dans quelques jours.

___
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





--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list

Re: [Talk-it] MAPUTNIK E LEAFLET

2018-04-04 Per discussione Stefano

Ciao,
secondo me è solo sbagliata la stringa, in realtà dovrebbe accettare tiles
png.
Generi le tiles con qtiles (https://plugins.qgis.org/plugins/qtiles/) e le
metti in una cartella del tuo webserver, poi metti il riferimento nella
configurazione tipo
http://localhost/tiles/{x}/{y}/{z}.png

Ciao

Il giorno 4 aprile 2018 18:23, Roberto Brazzelli 
ha scritto:

>
> Ciao Stefano,ne approfitto in merito a maputnik.. sai darmi indicazioni
> su come inserire un mio file raster?
> Il formato deve essere un url di riferimento al server
> https://openmaptiles.org/
> che ho installato in locale tipo http://localhost:3000/{x}/{y}/{z}.pbf ma
> non
> riesco a convertire un .tif in .pbf. Con qgis riesco a convertire in .xyz
> ma poi mi blocco...grazie
>
> Roberto
>
>
> Il giorno 28 marzo 2018 16:37, Stefano  ha scritto:
>
>>
>>
>> Il giorno 28 marzo 2018 16:08, Roberto Brazzelli <
>> geom.brazze...@gmail.com> ha scritto:
>>
>>> Ciao, ho creato un mio stile con l'editor
>>> on line maputnik e voglio inserire questo
>>> stile (nomefile.json) come sfondo nella mia mappa creata
>>> con leaflet o in alternativa in qgis.
>>> Qualcuno sa darmi indicazioni?
>>>
>>
>> Ciao,
>> per Leaflet ti serve Mapbox GL e mapbox-gl-leaflet.
>> Trovi il plugin con esempi qui
>>
>> https://github.com/mapbox/mapbox-gl-leaflet
>>
>>
>>> grazie
>>>
>>>
>> Ciao,
>> Stefano
>>
>>
>>> ___
>>> 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-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Import station essence

2018-04-04 Per discussione Stéphane Péneau


La réponse est envoyée :
https://lists.openstreetmap.org/pipermail/imports/2018-April/005477.html

Stéphane

Le 04/04/2018 à 10:46, Marc Gemis a écrit :

A lot of fuel stations can be use 24/7 with a bank card
-->
A lot of fuel stations can be used 24/7 with a bank card

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




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

[Talk-de] Flächen/Wege // Trolling in changesets

2018-04-04 Per discussione Michael Reichert

Hallo Flo,

Am 02.04.2018 um 20:00 schrieb Florian Lohoff:
> On Mon, Apr 02, 2018 at 05:14:33PM +0200, Michael Reichert wrote:
>> Halb-OT: Hat eigentlich schon einmal jemand™ untersucht, ob das
>> Verkleben oder das Nichtverkleben in Deutschland bezogen auf die Fläche,
>> die Anzahl der Objekte und die Anzahl der Benutzer dominierend sind?
> 
> Nicht verkleben ist dominant.
> 
> Ich habe mir ja software mit libosmium geschrieben die ein pbf
> file auswertet und eine sqlite schreibt mit den ganzen "segmenten"
> die verklebt sind (Also immer weg zwischen 2 nodes).

An dem Quellcode wäre ich interessiert, um es mal bundesweit laufen zu
lassen. Ich habe im Sommer 2015 eine Abstimmung auf Haralds
Umfrageplattform gemacht, bei der die Nichtkleber in der Mehrheit waren.
[1, 2, 3, 4]

Ich bin sehr daran interessiert, die Abstimmung mit den Füßen
auszuwerten, und würde mich freuen, wenn du deinen Code entweder mir zur
Verfügung stellen könntest oder gleich als freie Software
veröffentlichen könntest. Die Auswertung ist nicht ganz einfach, weil
man weder einfach die Objekte noch die Länge noch den Flächeninhalt
zählen muss, sondern auch beachten muss, wer was beigetragen hat.

Viele Grüße

Michael

[1] https://lists.openstreetmap.org/pipermail/talk-de/2015-July/111456.html
[2] https://lists.openstreetmap.org/pipermail/talk-de/2015-July/111527.html
[3] https://forum.openstreetmap.org/viewtopic.php?id=31807
[4] https://forum.openstreetmap.org/viewtopic.php?id=31845

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)

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

Re: [OSM-talk] Help me build an OSM Community Index

2018-04-04 Per discussione Bryan Housel

Yep, to echo what Clifford said - we don’t need to get the exact boundaries 
perfect.  As long as a person editing around this area sees that there is 
something nearby, I am happy.  

Because the project is really just a bunch of .geojson files, we can be 
flexible and update as often as needed.
For comparison, here are the current Pacific Northwest community boundaries:

Vancouver:  
https://github.com/osmlab/osm-community-index/blob/master/features/north-america/canada/vancouver_metro.geojson
 

Mt Vernon:  
https://github.com/osmlab/osm-community-index/blob/master/features/north-america/us/mt_vernon_wa.geojson
 

Seattle:  
https://github.com/osmlab/osm-community-index/blob/master/features/north-america/us/seattle.geojson
 


> On Apr 4, 2018, at 11:58 AM, Clifford Snow  wrote:
> 
> Paul,
> For this application having a well defined region isn't a big issue. To me 
> it's more of "if you are interested, here is a  nearby OSM group(s)." I think 
> as we learn how users react to the feature, we can find ways to improve it.  
> To that end, I gave Metro Vancouver as an area to github issue. It probably 
> should extend out more than just the metro relation but I felt it was a good 
> start.
> 
> Clifford
> 
> On Wed, Apr 4, 2018 at 2:50 AM, Paul Norman  > wrote:
> On 3/31/2018 5:25 AM, Bryan Housel wrote:
> a `.geojson` file to describe where the region where it is active.  (multiple 
> resources can share a .geojson file)
> 
> I'm having trouble figuring out what a sensible region is for the meetups in 
> Vancouver and the Pacific Northwest.
> 
> Our meetups are along the coast, but I don't believe there are any other 
> meetups for a few hundred km as you go inland. Closer to home, I'd consider 
> Chilliwack part of our region in many ways, but it's 100km from there to our 
> normal meeting place. This makes it too far to suggest, because it's a 90+ 
> minute drive. Where would I cut it off?
> 
> Going up and down the coast, we have a different problem. Vancouver, 
> South-Central Salish Sea, and Seattle all share a meetup organization, and 
> have overlap in members. The boundaries here are fuzzy.
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk 
> 
> 
> 
> 
> -- 
> @osm_seattle
> osm_seattle.snowandsnow.us 
> OpenStreetMap: Maps with a human touch
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

> Sent: Wed, 4 Apr 2018 16:39:05 +0200 
> From: "Martin Koppenhoefer" 
> To: "Openstreetmap allgemeines in Deutsch" 
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> D.H. wer den Zaun einzeichnen will muss zwangsläufig die Fläche mühsam von 
> der Straße trennen. Und wenn es da keinen Zaun gibt, irgendwas wird der 
> Mapper immer finden, was er da mappen will ;-)
> 
> Leben und leben lassen funktioniert am besten mit relativ wenigen, aktiven 
> Mappern, die sozusagen „ihr“ Gebiet haben (und einen bestimmten „Maßstab“ im 
> Kopf haben), aber wenn dann von vielen Leuten „wild“ Sachen ergänzt werden 
> (was wir ja gerade wollen), führt das oft zu einem Wulst (insbesondere von 
> Topologieproblemen).
> 

Es ist der technischen Entwicklung _und_ der Verfügbarkeit detaillierter 
Luftbilder geschuldet, dass oft keine Flächen mehr an Straßen geklebt werden.  
D.h. zum Einen ist es möglich, die Straßen- und Bahnanlagen als das zu 
Erfassen, was sie sind (Flächen) und zum Anderen ist es nicht mehr nötig, 
übermäßig darauf zu achten, dass alles in 8 kilobyte passt (mal übertrieben 
dargestellt).

Es ging hauptsächlich darum, aufzuzeigen, warum manche Daten so in der DB als 
Bestandsdaten vorhanden sind, wie sie es derzeit eben sind - und dass diese 
Varianten unter bestimmten Umständen (je nachdem was als Ziel angesehen wird) 
auch ihre Vorteile besitzen.  

OSM hat auch mehrmals den Fokus verschoben, eine reine Straßenkarte ist es 
schon lange nicht mehr.  Je mehr spezialisierte Details addiert werden, desto 
häufiger wird aber der Wunsch anzutreffen sein, vorgefilterte (oder 
umgerechnete) Datensätze zu nutzen.  OsmAnd z.B. errechnet seit längerer Zeit 
reine Straßenkarten und filtert
damit den ganzen Rest aus den Daten heraus.  Zusammen mit ein paar Algorithmen 
zur Knotenreduktion läuft das Ergebnis auch auf älteren, weniger 
leistungsfähigen Geräten und bedient damit ein breiteres Spektrum an 
Anwendungsfällen.

Und wer den Zaun einzeichnet, muss die Fläche nicht trennen, sofern er das 
nicht kann/will.  Diesen Job kann auch ein anderer Mapper übernehmen..


Gruß
cmuelle8

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

> Sent: Wed, 4 Apr 2018 17:38:23 +0200
> From: "Florian Lohoff" 
> To: "Christian Müller" 
> Cc: talk-de@openstreetmap.org
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Ich hatte ja in dem Thread auch ausgeführt das es ein Problem gibt mit
> neumappern. Das Thema MP Relation und die Wege alle einzeln hinzufügen
> ist noch eine viel größeres Pflegedesaster. Ich gebe dir Recht das das
> eine total saubere Sache ist (Syntaktisch) - Aber leider ist das eben
> für "gelegenheitsmapper" völlig ungeeignet.

Und wieder und wieder werden Leute bevormundet, die du überhaupt nicht
kennst, nie in deinem Leben gesehen hast, mit Behauptungen, die einzig
und allein einem Bauchgefühl (und vielleicht ein paar Beobachtungen in
den Daten) entspringen zu scheinen.

Der "Gelegenheitsmapper", das ist so der "Ottonormalverbraucher" oder
der "Kleine Mann", jeder will ihn kennen, nie hat ihn jemand gesehen
oder verstanden.

Wieviel Projekte wird das Internet noch sehen müssen, bevor sich der
letzte von solchen Aussagen trennt?

Du unterschlägst sowohl Intelligenz, Wissbegier, Neugier, Lernfähigkeit
der freiwilligen Mapper, imho.  Vielleicht liegt dein Fokus auch zu sehr
auf den vermeintlichen Problemen, anstatt zu sehen, dass eine ganze
Menge an Edits eben nicht fehlerbehaftet ist.


Gruß
cmuelle8

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

> Sent: Wed, 4 Apr 2018 16:22:05 +0200
> From: "Hartmut Holzgraefe" 
> To: talk-de@openstreetmap.org
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Verklebt man Flächen und Wege dann verschwindet eine eigentlich
> vorhandene Lücke.
> 
> Stoßen zwei Flächen dagegen tatsächlich direkt aneinander, zB.
> ein Waldstück und eine Wiese, dann ist es kein Problem wenn diese
> beiden sich eine Grenzlinie teilen. Darum geht es in diesem Thread
> aber nicht, sondern konkret um das "verkleben" von Objekten 
> unterschiedlicher Dimension: zweidimensionale Flächen mit
> eindimensional erfassten Stra0en und Wegen.

Ok, das habe ich verstanden.  Du hast aber nicht verstanden, dass
wir auch die neu gebildeten Flächen wiederum genauer mappen können,
wenn wir nur genau genug hinschauen.  Und immer wieder
ergeben sich dieselben Fragen:

Was ist dazwischen, sollten wir nicht eine Lücke lassen?
Oder sollten wir die Lücke unterschlagen, weil sie unter
gegebenen Umständen nicht relevant erscheint?

Vielleicht läuft auf der Waldgrenze ein Weg, der hat, bei genauer
Betrachtung eine Fläche, also grenzt dann nicht Wald an Wiese,
sondern Wald an Weg und Weg an Wiese, nicht?


"Eindimensional erfasst" heißt eben nicht "eindimensional vor Ort".
Das Wege, Straßen und Bahnlinien Fläche verbrauchen, wird einem
schon dann bewusst, wenn genügend Bäume für Straßen, Wege, Bahn-
linien, Stromtrassen, Pipelines, aber auch Feuerschutzstreifen
abgeholzt wurden.

Nochmal, das Problem ist eines der Abwägung:  Wieviel Detail soll
erfasst werden und wieviel Detail darf durch Abstraktion verloren
gehen!?

Wenn der Straßengraben, der ja i.d.R. linear an der Straße entlang
läuft, als Teil der (linear erfassten) Straße aufgefasst wird,
sprich er mit der Gesamtstraßen-Anlage gemeinsam abstrahiert
wird und der Straße eine Standardbreite (oder eine per tag er-
fasste) zugewiesen wurde, /dann/ ist es auch eine sinnvolle und
effiziente Repräsentation, die lineare Repräsentation der Gesamt-
anlage als Flächengrenze wiederzuverwenden.

Wie bereits gesagt, entsteht dadurch ein Fehler (abstraktions-
bedingt), der bei der Flächenberechnung aber z.B. dadurch min-
imiert werden kann, dass (Länge*getaggte Breite)/2 von der Be-
rechnung der Flächengröße der geklebten Fläche abgezogen werden
kann.  /Wenn/ alle Flächen so gemappt würden, dann ist das auch
programmatisch einfachst umzusetzen, dann programmiert man das
einmal und gut ist.

Soll der Straßengraben hingegen als separate Fläche erfasst
werden, weil festgestellt wurde, dass die Abstraktion zu stark
abstrahiert und oft nicht der Situation vor Ort entspricht,
dann braucht man eben ein paar Linien mehr:  Die vom Acker
zum Graben, die vom Graben zur Straßenkante.  Wird der Graben
mit riverbank=* erfasst, dann können das schon vier parallele
Linien sein:

Je nachdem wie genau man hinschaut, lassen sich also mehr und
mehr Flächen (und damit auch Flächengrenzen) identifizieren,
aber es ist Unsinn, eine Lücke herzustellen, ohne diese dann
auch als getaggte Fläche auszuzeichnen.

Es steht eine Gesamtfläche zum Mappen zur Verfügung und die
Frage ist, wie genau und wo man sie unterteilt, um Teilflächen
zu beschreiben.  Das kann z.B. grob mit "Harz", "Alpen" oder
"Wassereinzugsgebiet der Elbe" geschehen oder etwas genauer
mit "Berliner Stadtbibliothek".

Weder die (groben) Grenzen von Gebirgen, noch die genaueren
der Stadtbibliothek verschwinden dadurch, dass in ihren Gren-
zen weitere flächenhafte Objekte identifiziert werden (etwa
durch Indoor-Mapping der Stadtbibliothek oder der Erfassung
von einzelnen Forstgebieten oder Stauseen im "Harz").

Und auch das Phänomen, dass eine Fläche an eine andere an-
schließt, wird sich durch Lückenbildung (egal aus welcher
Motivation heraus) nicht egalisieren, wobei es unerheblich
ist, auf welcher Detailstufe dieses Phänomen untersucht
wird.  Man ziehe beispielhaft die naturräumliche Gliederung
Deutschlands oder anderer Länder zu rate.  Die hier benutzten
Grenzen bilden teilweise /Streifen/, die mehrere Kilometer
mächtig sind, die auf anderen Detailstufen weitere Flächen
enthalten, ohne dabei aber den Aspekt des "aneinandergeklebt"-
seins zu verlieren.


> > Du kannst den Missstand mit den overlapping ways beenden,
> > indem du MP bildest, die sich der geometrisch korrekt
> > eingetragenen Flächengrenzen(-teile) bedienen.
> 
> Das verstehe ich nicht, das verkompliziert die Sache doch eher
> noch mehr, wie wir an den immer wieder kaputt gehenden 
> Verwaltungsgrenzen und Küstenlinien regelmäßig leidvoll erfahren ...

Das ist zum Teil ein Bildungsproblem.  Es ist eben nicht zu
vermeiden, dass unerfahrene Nutzer auch mal etwas kaputt machen.

Zur Abhilfe gibt es mehrere Kommunikationswege, die Changeset-
Kommentarfunktion, das Wiki, etc. pp. - es wäre aber imho falsch,
das Datenmodell an der Unerfahrenheit auszurichten, so dass es dann
nicht mehr adäquat die Situation vor Ort / am Boden repräsentiert.

Ich bin Vereinfachungen gegenüber

Re: [Talk-it] MAPUTNIK E LEAFLET

2018-04-04 Per discussione Roberto Brazzelli

Ciao Stefano,ne approfitto in merito a maputnik.. sai darmi indicazioni
su come inserire un mio file raster?
Il formato deve essere un url di riferimento al server
https://openmaptiles.org/
che ho installato in locale tipo http://localhost:3000/{x}/{y}/{z}.pbf ma
non
riesco a convertire un .tif in .pbf. Con qgis riesco a convertire in .xyz
ma poi mi blocco...grazie

Roberto


Il giorno 28 marzo 2018 16:37, Stefano  ha scritto:

>
>
> Il giorno 28 marzo 2018 16:08, Roberto Brazzelli  > ha scritto:
>
>> Ciao, ho creato un mio stile con l'editor
>> on line maputnik e voglio inserire questo
>> stile (nomefile.json) come sfondo nella mia mappa creata
>> con leaflet o in alternativa in qgis.
>> Qualcuno sa darmi indicazioni?
>>
>
> Ciao,
> per Leaflet ti serve Mapbox GL e mapbox-gl-leaflet.
> Trovi il plugin con esempi qui
>
> https://github.com/mapbox/mapbox-gl-leaflet
>
>
>> grazie
>>
>>
> Ciao,
> Stefano
>
>
>> ___
>> 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-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Tag pour "chaussées à voie centrale banalisée" ?

2018-04-04 Per discussione marc marc

Le 04. 04. 18 à 16:36, Shohreh a écrit :

> Même aux Pays-Bas, il ne semble pas exister de tag simple pour un
> "fietsstrook" (pl : fietsstroken); ils recommendent d'utiliser
> highway= + cycleway=shared_lane :
> 
> https://wiki.openstreetmap.org/wiki/NL:Cycleway#Fietsstroken_2
> https://nl.wikipedia.org/wiki/Fietsstrook

non c'est incohérent.
cycleway=shared_lane implique que la bande est partagée.
une bande réservée aux cyclistes n'est pas partagée.

 > Rue de la Minière à Buc (banlieue sud de Paris),
 > c'est simplement taggé comme ça :
 > https://s17.postimg.org/6840jnl8v/Chaucidou.rue.de.la.Miniere.Buc.OSM.png

 > Ça semble plutôt mieux, non ?
 > 1. Laisser le défaut "Oneway=no"
 > 2. Modifier "cycleway" en "both"
 > 3. Ajouter "lanes=1"
 > 
https://s17.postimg.org/pv2f8xx3z/Chaucidou.rue.de.la.Miniere.Buc.OSM.suggestion.png

suggestions :)
- faire un email au lieu de 3 :)
- cycleway:left=lane+cycleway:right=lane indique qu'il y a une bande
à gauche ET une bande à droite.
La vue sat a l'air de correspondre à cela.
c'était exactement aussi le même sens que cycleway=lane existant
La situation existant était parfaitement juste.
j'aime bien quand quelqu'un demande si c'est mieux la modif
qu'il veux faire mais la fait sans attendre la réponse :)
il y a plus qu'à revenir en arrière :)
parce que cycleway=both ne veux rien dire. puisque la valeur de cycleway 
est le type d'aménagement (une bande isolée ou partageée ou en sens 
inverse).
sans doute voulais-tu dire cycleway:both=lane qui correspond exactement 
à la description de cycleway=lane (on ne met pas de sufixe :both quand 
les 2 sont identiques)

Quand à l'exemple initial d'une bande CENTRALE cela nécessiterait
un cycleway:center=lane (probablement non utilisé par les apps
mais c'est un autre débat).
J'ignore si c'est le cas pour la rue de la Miniere
la vue sat montre des voitures au centre, j'ignore s'ils sont en 
infraction ou si la situation a changé ou si tu parlais d'un autre cas

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

Re: [OSM-talk] Help me build an OSM Community Index

2018-04-04 Per discussione Clifford Snow

Paul,
For this application having a well defined region isn't a big issue. To me
it's more of "if you are interested, here is a  nearby OSM group(s)." I
think as we learn how users react to the feature, we can find ways to
improve it.  To that end, I gave Metro Vancouver as an area to github
issue. It probably should extend out more than just the metro relation but
I felt it was a good start.

Clifford

On Wed, Apr 4, 2018 at 2:50 AM, Paul Norman  wrote:

> On 3/31/2018 5:25 AM, Bryan Housel wrote:
>
>> a `.geojson` file to describe where the region where it is active.
>>  (multiple resources can share a .geojson file)
>>
>
> I'm having trouble figuring out what a sensible region is for the meetups
> in Vancouver and the Pacific Northwest.
>
> Our meetups are along the coast, but I don't believe there are any other
> meetups for a few hundred km as you go inland. Closer to home, I'd consider
> Chilliwack part of our region in many ways, but it's 100km from there to
> our normal meeting place. This makes it too far to suggest, because it's a
> 90+ minute drive. Where would I cut it off?
>
> Going up and down the coast, we have a different problem. Vancouver,
> South-Central Salish Sea, and Seattle all share a meetup organization, and
> have overlap in members. The boundaries here are fuzzy.
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>



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

Re: [OSM-talk-fr] Tag pour "chaussées à voie centrale banalisée" ?

2018-04-04 Per discussione JB


Le 04/04/2018 à 16:47, Shohreh a écrit :

2. Modifier "cycleway" en "both"
Pas mentionné dans le wiki, peu utilisé (11 fois en France, 24000 fois 
pour lane).


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

Re: [OSM-talk-fr] Rapprochement des adresses OSM et FANTOIR

2018-04-04 Per discussione deuzeffe


Le 03/04/2018 à 15:06, Vincent de Château-Thierry a écrit :

Bonjour,


Bonjour,

L'anomalie que tu soulignais est normalement corrigée désormais. Elle 
était liée à un bug sur le traitement des suffixes (la commune de 
Perpignan est concernée) qui faisait en cascade planter toutes les mises 
à jour de la commune.


=> https://github.com/osm-fr/bano/issues/146


Est-ce qu'on peut supposer que la correction du bug concerne tout le 
territoire (ou suis-je trop pressée ;p) ?


Parce que le problème (constaté depuis plusieurs mois sans oser trop 
dire quoi que ce soit ^^) persiste (vérifié à l'instant) dans mon coin, 
par exemple ici : 
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#15/45.8138/1.1464


Merci pour la réponse, quelle qu'elle soit.
--
deuzeffe - impatiente

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

On Wed, Apr 04, 2018 at 04:16:39PM +0200, "Christian Müller" wrote:
> Vielleicht ist es besser zwischen
> 
> - allgemeinem "Verkleben" von Flächen
> 
> - "Verkleben" von Flächen mit highway=*
> 
> zu unterscheiden und zusätzlich zu erklären,
> ob "Verkleben" nur die Bildung von Flächen
> mit overlapping ways oder auch mit der Wie-
> derverwendung von ways in MP meint.  Imho
> wird derzeit sowohl das eine als auch das
> andere darunter verstanden, d.h.
> 
> nicht verkleben == "Luft" zwischen Flächen

Es ist noch differenzierter - 

- Verkleben von Flächen unterschiedlicher Dimension d.h.
  z.b. highway, waterway und Flächen landuse, landcover, leisure,
  natural, amenity

- Verkleben von Flächen unterschiedlicher klasse d.h. landuse mit
  leisure oder landuse mit amenity.

Beides versuche ich wo es nur geht zu vermeiden. Ein amenity=parking
in einem landuse=graveyard oder landuse=commercial versuche ich nicht
zu verbinden. Und wenn man nur genau genug hin sieht ist es meistens
auch geometrisch richtig das nicht zu verbinden. Und es ist für 
den "gelegenheitsmapper" auch viel klarer was gemeint ist.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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

Re: [OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO

2018-04-04 Per discussione Vincent Frison

En fait d'après cette page  l'IGN a
visiblement obtenu l'an passé une dérogation pour continuer à utiliser leur
licence actuelle pour la BD TOPO (entre autres) jusqu'au 4 mai 2018. Mais
peut-être qu'à partir de ce moment là ils seront obligés d'utiliser une
licence ouverte !

*La « licence d’utilisation à titre gratuit
 » de l’institut
national géographique et forestier (IGN) est homologuée par la décision
d'homologation

du
5 mai 2017 pour le périmètre des données géographiques BD ORTHO®, BD TOPO®,
BD PARCELLAIRE®, BD ADRESSE® et RGE ALTI®  jusqu'au 4 mai 2018.*

Et au pire, même s'ils arrivent encore à repousser encore la date,
peut-être qu'on pourrait effectivement leur demander une autorisation
spéciale pour OSM (au moins pour les hauteurs de bâtiments).

++ Vincent.


Le 4 avril 2018 à 11:14, Vincent Frison  a écrit :

> Hello,
>
> Il semblerait que les choses doivent bientôt changer du côté de l'IGN et
> qu'ils vont devoir à (court?) terme devoir libérer leur données. Cela
> pourrait être fantastique pour OSM notamment pour leur BD TOPO. Quelqu'un
> aurait des infos plus précises à ce sujet ?
>
> Dans le passé j'avais fait des scripts
>  pour importer les hauteurs
> de bâtiments à partir de diverses sources de données (notamment des
> combinaisons de MNT et MNS). C'était bien mais c'était assez laborieux et
> surtout ça ne concernait que quelques grandes villes (je l'avais fait que
> pour Paris, Nice et Montpellier).
>
> Mais là avec  cette BD TOPO on aurait tout le travail déjà fait (et bien
> fait j'espère).. et sur l'ensemble du pays !!!
>
> Clairement si l'IGN passe ce jeu de données en Licence Ouverte ou ODbL
> (comme cela est préconisé par l'Etat) j'aimerais bien réutiliser mes
> scripts pour faire l'import dans OSM. Je parle uniquement des hauteurs de
> bâtiment, mais il y aura certainement un paquet d'autres choses à
> récupérer...
>
> ++ Vincent.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Flächen/Wege // Trolling in changesets

On Wed, Apr 04, 2018 at 04:00:28PM +0200, "Christian Müller" wrote:
> 
> Du kannst den Missstand mit den overlapping ways beenden,
> indem du MP bildest, die sich der geometrisch korrekten
> eingetragenen Flächengrenzen(-teile) bedienen.
> 

Ich hatte ja in dem Thread auch ausgeführt das es ein Problem gibt mit
neumappern. Das Thema MP Relation und die Wege alle einzeln hinzufügen
ist noch eine viel größeres Pflegedesaster. Ich gebe dir Recht das das
eine total saubere Sache ist (Syntaktisch) - Aber leider ist das eben
für "gelegenheitsmapper" völlig ungeeignet.

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away

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

Re: [OSM-talk-fr] Tag pour "chaussées à voie centrale banalisée" ?

2018-04-04 Per discussione Philippe Verdy

effectivement pour une seule voie cyclable bidirectionnelle, mettre
cycleway:left=lane+cycleway:right=lane est faux puisque cela implique deux
voies cyclables séparées, une de chaque côté de la route. Pour le cas
présent c'est une voie cyclable centrale unique qui sépare les deux voies
de la chaussée et ce n'est ni à droite ni à gauche... mais où placer alors
ce way ?

Ne serait-ce pas quelquechose comme
 cycleway:center=lane +
 cycleway:lanes=1 +
 cycleway:oneway=no ?

S'il y a une barrière ou un rebord (kerb) interdisant les franchissements
par les non-cycles et dans ce cas, la rue devrait être tracée avec deux
ways parallèles en sens uniques opposés, mais alors la voie cyclable
séparée physiquement (éventuellement sur le terre-plain central) est à
tracer en plus en parallèle entre les deux et c'est une simple
"highway=cycleway"+"lanes=1"+"oneway=no".

On a aussi le cas de voies banalisées centrales pour bus: parfois
bidirectionnelle (2 voies pour permettre les croisements), mais alors ces
"highway=busway" sont tracés sur la ligne centrale de séparation des voies
avec "lanes=2" et oneway=no, et on peut ajouter "cycleway=share_lane" pour
indiquer qu'ils utilisent les voies bus et n'ont pas de voies spécifiques
pour eux. Dans certains cas le "highway=busway" est à sens unique
(oneway=yes, lanes=1), partageable par les vélos, cycleway=share_lane) mais
il peut être prévu aussi une voie cyclable étroite en contre sens, du côté
gauche du "highway=busway"+"oneway=yes" (remplacer "cycleway=share_lane",
par "cycleway:left= opposite_lane" " + "cycleway:right=share_lane", car ici
on suppose que le busway à sens unique est tracé dans le même sens que le
sens unique; et ici je suppose que la voie en contre sens reste à gauche,
si ce n'est pas le cas on aura plutôt "cycleway:right=lane" +
"cycleway:left=opposite_lane").

La solution néerlandaise du "fietsstrook" me semble incorrecte concernant
le nombre total de "lanes" où ils ont en fait tagué deux pistes cyclables
séparées de chaque côté de la route, même avec lanes=1 qui concerne le
nombre de voies de la route non-cyclable...


2018-04-04 16:47 GMT+02:00 Shohreh :

> Ça semble plutôt mieux, non ?
>
> 1. Laisser le défaut "Oneway=no"
> 2. Modifier "cycleway" en "both"
> 3. Ajouter "lanes=1"
>
> https://s17.postimg.org/pv2f8xx3z/Chaucidou.rue.de.la.
> Miniere.Buc.OSM.suggestion.png
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] YHA (England & Wales), Youth Hostel

2018-04-04 Per discussione Adam Snape

Of course, if they happen to have suitable GIS data for their locations and
were willing to allow us to reuse these and the details on their website
under the ODBL, then it would be a very helpful dataset. We could use it to
keep track of the frequent closur ahem... changes to the YHA network.

Regards,

Adam

On 4 April 2018 at 13:26, Adam Snape  wrote:

> +1
>
> Permission to add something to a map is certainly not the same as
> permission to release information under the ODBL, we need that explicitly
> stated.
>
> Also, how are you going to locate the hostels? I'm assuming you're
> armchair mapping, so how can you tell whether (or which) hostel mapped in
> OSM is the relevant YHA one? Any information derived from the Google maps
> on the YHA site is strictly unuseable, even with YHA's permission.
>
> Kind regards,
>
> Adam Snape
>
> On 4 April 2018 at 13:08, Dan S  wrote:
>
>> Hi
>>
>> "YHA (England & Wales)" would go in the "operator" field, not appended
>> to the "name". (I'm not sure which you were suggesting.)
>>
>> I'm pretty sure that the loose permission (that you quote) is not
>> technically enough to safely use the YHA's own list as a source of
>> data for OSM, though it seems they're likely to be brodly in favour.
>> With a bit more chat with them, and some reassurance that we're not
>> intending to infringe on their copyrights, you can probably get
>> something like an explicit permission to add the data to OSM under
>> ODBL.
>>
>> Best
>> Dan
>>
>>
>> 2018-04-04 12:39 GMT+01:00 David Vere :
>> > I've made an enquiry to YHA England & Wales and have been told that
>> while
>> >
>> > "names of the individual hostels and YHA (England & Wales) as well as
>> Youth
>> > Hostel are all copyrighted”
>> >
>> > they are
>> >
>> > "happy for you to use the names on a map"
>> >
>> > and will even supply a current list.
>> >
>> > Is there any objection to my attaching the YHA hostel name and "YHA
>> (England
>> > & Wales)" to the hostels that are on openstreetmap.
>> >
>> > David
>> >
>> >
>> >
>> > ___
>> > Talk-GB mailing list
>> > Talk-GB@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-gb
>> >
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] QA bots commenting on changesets - your thoughts?

2018-04-04 Per discussione john whelan

> * do not message the same person twice about the same kind of problem

and I would support this.  The other problem is how recent was the
mapping.  If its more than a week old they may have corrected the way they
work after it had been brought to their attention by another mapper.

Cheerio John

On 4 April 2018 at 10:53, Frederik Ramm  wrote:

> Hi,
>
> On 04/04/18 10:44, Michał Brzozowski wrote:
> > What do you think about it? Are such bots useful or not?
>
> The bot programmer must take extreme care not to make their bot an
> annoyance. In my opinion this would include:
>
> * do not message the same person twice about the same kind of problem
>
> * at the very least allow mappers to "opt out" of bot messaging, or
> ideally use an opt-in where when someone submits a changeset, they don't
> only tick "I would like someone to review my changeset" but also "I am
> willing to receive automated messages about this changeset"
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] QA bots commenting on changesets - your thoughts?

2018-04-04 Per discussione Frederik Ramm

Hi,

On 04/04/18 10:44, Michał Brzozowski wrote:
> What do you think about it? Are such bots useful or not?

The bot programmer must take extreme care not to make their bot an
annoyance. In my opinion this would include:

* do not message the same person twice about the same kind of problem

* at the very least allow mappers to "opt out" of bot messaging, or
ideally use an opt-in where when someone submits a changeset, they don't
only tick "I would like someone to review my changeset" but also "I am
willing to receive automated messages about this changeset"

Bye
Frederik

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

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

Re: [OSM-talk-fr] Tag pour "chaussées à voie centrale banalisée" ?

Ça semble plutôt mieux, non ?

1. Laisser le défaut "Oneway=no"
2. Modifier "cycleway" en "both"
3. Ajouter "lanes=1"

https://s17.postimg.org/pv2f8xx3z/Chaucidou.rue.de.la.Miniere.Buc.OSM.suggestion.png



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-it] Import Dati regione Puglia

2018-04-04 Per discussione Francesco Piero Paolicelli

si dicevo proprio quello :)


Il giorno 4 aprile 2018 16:25, Luca Riccardi  ha
scritto:

> @Francesco: In parole povere, mi stai dicendo che questi dataset
> convoglieranno nel portale viaggiare in puglia e quindi, sicuramente,
> saranno oggetto dell'import planning.  :)
> Per quanto riguarda  CulturalON, non saprei dirti... forse sei più
> aggiornato tu di me. :)
>
> Luca
>
>
> Il giorno 4 aprile 2018 15:23, Francesco Piero Paolicelli <
> pierso...@gmail.com> ha scritto:
>
>> @luca solo brevemente.
>> i dataset di Viaggiare in Puglia e quelli della Digital Library verranno
>> adeguati agli standard CulturalON.
>> I portali Terra delle Gravine e Salentojonico.it hanno già i luoghi della
>> cultura e la digital library adeguati. La regione si uniformerà agli
>> standard Mibact quanto prima.
>> Mi sono solo portato il lavoro avanti su questi portali opendata perchè
>> li ho gestiti io.
>> Anzi, Viaggiare in Puglia importerà tutti i dati dei portali che ti ho
>> citato per accrescere il proprio database. Per esempio solo su Massafra
>> Viaggiare in puglia aveva 10-15 luoghi, sul portale terra delle gravine
>> solo su massafra ce ne sono 130.
>>
>> buon import.
>> p
>>
>> Il giorno 4 aprile 2018 15:06, Luca Riccardi  ha
>> scritto:
>>
>>> @Federico,  grazie per la disponibilità, notificherò quanto detto a
>>> riguardo delle chiese (ma esteso in generale) a chi processerà gli import.
>>>
>>> @Francesco,  per ora è previsto il mapping dei beni culturali  presenti
>>> sui portali Viaggiare in puglia e Digital Library.
>>> Lo scopo principale è andare a mappare su OSM il bene culturale e la
>>> referenza annessa al portale di origine... questo è un tassello di un
>>> progetto più ampio!
>>> Ovviamente se si costituisse un "dizionario universale" raffinato dalla
>>> comunità, dove a prescindere dalla lingua, un determinato tipo di nodo
>>> viene mappato allo stesso modo (ad esempio chiesa prevederà sempre i tag
>>> evidenziati da Federico) a mio parere, potrebbe essere una cosa buona per
>>> tutti ed allo stesso tempo offrire un minimo di standard nel mapping* visto
>>> che adesso  mi è parso di capire che la scelta del tag dipende fortemente
>>> dal mapper.
>>>
>>> *ovviamente si tiene in considerazione che ci possano essere delle
>>> eccezioni.
>>>
>>> una curiosità... non ho ben chiaro se posso considerare "concessa"
>>> l'autorizzazione agli importo... o in caso negativo come continua l'iter! :)
>>>
>>> Il giorno 4 aprile 2018 14:32, Federico Cortese 
>>> ha scritto:
>>>
 2018-04-04 13:49 GMT+02:00 Luca Riccardi :

 > Anzi se posso approfittare: chi si occuperà del mapping della
 categoria col
 > tag (popolamento del dizionario) potrebbe contattarti in casi di
 dubbi o
 > verificare se il mapping pensato è corretto?!

 Certamente

 > -chiese: dici che buona parte sono presenti (come poligoni  e non
 semplici
 > punti aventi il tag amenity=place_of_worship ), ma il sprovvisti del
 tag
 > name?

 Sì, quando ho impostato l'import per i fabbricati ho assegnato
 building=church + amenity=place_of_worship + religion=christian alle
 chiese.
 Quindi a parte quelle realizzate dopo il 2006 (data a cui risaliva
 l'elaborazione della CTR), tutte le altre sono già presenti come
 poligono edificato.
 In fase di conflation, nell'eseguire l'import, abbiamo trasferito ai
 nuovi fabbricati tutti i tag già presenti sui vecchi poligoni o sui
 nodi.
 Altre chiese sono state mappate successivamente all'import, ma
 moltissime sono ancora senza nome, pertanto questo import potrebbe
 permetterne il completamento.
 Purtroppo nei dati della CTR si sono verificate anche interpretazioni
 errate: mi è capitato di trovare chiese che in realtà sul posto erano
 normali abitazioni (magari di forma particolare) oppure chiese
 presenti sul posto che non erano state identificate come tali in fase
 di elaborazione della CTR; si tratta comunque di casi rari.
 Ecco un esempio di chiese senza nome nella mia zona:
 http://overpass-turbo.eu/s/xzK

 Ciao,
 Federico

 ___
 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-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-it mailing list

Re: [OSM-talk-fr] Tag pour "chaussées à voie centrale banalisée" ?

Rue de la Minière à Buc (banlieue sud de Paris), c'est simplement taggé comme
ça :

https://s17.postimg.org/6840jnl8v/Chaucidou.rue.de.la.Miniere.Buc.OSM.png



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

sent from a phone

> On 4. Apr 2018, at 15:43, Christian Müller  wrote:
> 
> Das Verkleben ist alternativlos!  Die Frage ist natürlich WO man verklebt
> _und_ welchen Detailgrad man anstrebt.

stimmt, was verbunden sein muss darf man natürlich auch nicht trennen, ich habe 
(in Deutschland) auch schon öfters gesehen, dass angrenzende Flächen jeweils 
eigene nodes hatten, die jeweils ganz nah nebeneinander standen, aber eben 
nicht verbunden waren. Das sehe ich auch als Problem.

Deine Aussage bezog sich vermutlich darauf, angrenzende Flächen mit dem highway 
zu verbinden, und da gebe ich dir Recht, dass das in bestimmten Maßstäben OK 
ist. In OSM haben wir aber keine Maßstäbe (außer dem, was wir mit der 
Koordinatengenauigkeit darstellen können, und was die Mapper eintragen wollen), 
zumindest ist das Mappen im Maßstab der Straße durchaus schon üblich, und da 
kollidiert das Generalisieren der Flächen damit, weil entweder der die Fläche 
begrenzende Zaun in der Straßenmitte läuft (und seine Form verloren geht), oder 
er läuft über die Fläche und nicht am Rand. 

D.H. wer den Zaun einzeichnen will muss zwangsläufig die Fläche mühsam von der 
Straße trennen. Und wenn es da keinen Zaun gibt, irgendwas wird der Mapper 
immer finden, was er da mappen will ;-)

Leben und leben lassen funktioniert am besten mit relativ wenigen, aktiven 
Mappern, die sozusagen „ihr“ Gebiet haben (und einen bestimmten „Maßstab“ im 
Kopf haben), aber wenn dann von vielen Leuten „wild“ Sachen ergänzt werden (was 
wir ja gerade wollen), führt das oft zu einem Wulst (insbesondere von 
Topologieproblemen).

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

Re: [OSM-talk-fr] Tag pour "chaussées à voie centrale banalisée" ?

Merci.

Même aux Pays-Bas, il ne semble pas exister de tag simple pour un
"fietsstrook" (pl : fietsstroken); ils recommendent d'utiliser
highway= + cycleway=shared_lane :

https://wiki.openstreetmap.org/wiki/NL:Cycleway#Fietsstroken_2
https://nl.wikipedia.org/wiki/Fietsstrook

Je vais utiliser ça, mentionné plus haut dans le fil :
lanes=1 + oneway=no + cycleway:left=lane + cycleway:right=lane



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk] QA bots commenting on changesets - your thoughts?

2018-04-04 Per discussione Bryan Housel

I think the more we can do to automate QA, the better.   

There should be some common sense guidelines for running bots though:
*  user names with “bot” in them
*  user profiles that say what the bot does and where the source code is
*  common place on GitHub for bot development (osmlab/bots?) 



> On Apr 4, 2018, at 4:44 AM, Michał Brzozowski  wrote:
> 
> There's a bot in Poland that comments on changesets which break addresses 
> (e.g. combining addr:place with addr:street), along with an explanation and 
> links to forum topic.
> 
> What do you think about it? Are such bots useful or not?
> 
> Michał
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

Re: [Talk-it] Import Dati regione Puglia

 @Francesco: In parole povere, mi stai dicendo che questi dataset
convoglieranno nel portale viaggiare in puglia e quindi, sicuramente,
saranno oggetto dell'import planning.  :)
Per quanto riguarda  CulturalON, non saprei dirti... forse sei più
aggiornato tu di me. :)

Luca


Il giorno 4 aprile 2018 15:23, Francesco Piero Paolicelli <
pierso...@gmail.com> ha scritto:

> @luca solo brevemente.
> i dataset di Viaggiare in Puglia e quelli della Digital Library verranno
> adeguati agli standard CulturalON.
> I portali Terra delle Gravine e Salentojonico.it hanno già i luoghi della
> cultura e la digital library adeguati. La regione si uniformerà agli
> standard Mibact quanto prima.
> Mi sono solo portato il lavoro avanti su questi portali opendata perchè li
> ho gestiti io.
> Anzi, Viaggiare in Puglia importerà tutti i dati dei portali che ti ho
> citato per accrescere il proprio database. Per esempio solo su Massafra
> Viaggiare in puglia aveva 10-15 luoghi, sul portale terra delle gravine
> solo su massafra ce ne sono 130.
>
> buon import.
> p
>
> Il giorno 4 aprile 2018 15:06, Luca Riccardi  ha
> scritto:
>
>> @Federico,  grazie per la disponibilità, notificherò quanto detto a
>> riguardo delle chiese (ma esteso in generale) a chi processerà gli import.
>>
>> @Francesco,  per ora è previsto il mapping dei beni culturali  presenti
>> sui portali Viaggiare in puglia e Digital Library.
>> Lo scopo principale è andare a mappare su OSM il bene culturale e la
>> referenza annessa al portale di origine... questo è un tassello di un
>> progetto più ampio!
>> Ovviamente se si costituisse un "dizionario universale" raffinato dalla
>> comunità, dove a prescindere dalla lingua, un determinato tipo di nodo
>> viene mappato allo stesso modo (ad esempio chiesa prevederà sempre i tag
>> evidenziati da Federico) a mio parere, potrebbe essere una cosa buona per
>> tutti ed allo stesso tempo offrire un minimo di standard nel mapping* visto
>> che adesso  mi è parso di capire che la scelta del tag dipende fortemente
>> dal mapper.
>>
>> *ovviamente si tiene in considerazione che ci possano essere delle
>> eccezioni.
>>
>> una curiosità... non ho ben chiaro se posso considerare "concessa"
>> l'autorizzazione agli importo... o in caso negativo come continua l'iter! :)
>>
>> Il giorno 4 aprile 2018 14:32, Federico Cortese 
>> ha scritto:
>>
>>> 2018-04-04 13:49 GMT+02:00 Luca Riccardi :
>>>
>>> > Anzi se posso approfittare: chi si occuperà del mapping della
>>> categoria col
>>> > tag (popolamento del dizionario) potrebbe contattarti in casi di dubbi
>>> o
>>> > verificare se il mapping pensato è corretto?!
>>>
>>> Certamente
>>>
>>> > -chiese: dici che buona parte sono presenti (come poligoni  e non
>>> semplici
>>> > punti aventi il tag amenity=place_of_worship ), ma il sprovvisti del
>>> tag
>>> > name?
>>>
>>> Sì, quando ho impostato l'import per i fabbricati ho assegnato
>>> building=church + amenity=place_of_worship + religion=christian alle
>>> chiese.
>>> Quindi a parte quelle realizzate dopo il 2006 (data a cui risaliva
>>> l'elaborazione della CTR), tutte le altre sono già presenti come
>>> poligono edificato.
>>> In fase di conflation, nell'eseguire l'import, abbiamo trasferito ai
>>> nuovi fabbricati tutti i tag già presenti sui vecchi poligoni o sui
>>> nodi.
>>> Altre chiese sono state mappate successivamente all'import, ma
>>> moltissime sono ancora senza nome, pertanto questo import potrebbe
>>> permetterne il completamento.
>>> Purtroppo nei dati della CTR si sono verificate anche interpretazioni
>>> errate: mi è capitato di trovare chiese che in realtà sul posto erano
>>> normali abitazioni (magari di forma particolare) oppure chiese
>>> presenti sul posto che non erano state identificate come tali in fase
>>> di elaborazione della CTR; si tratta comunque di casi rari.
>>> Ecco un esempio di chiese senza nome nella mia zona:
>>> http://overpass-turbo.eu/s/xzK
>>>
>>> Ciao,
>>> Federico
>>>
>>> ___
>>> 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-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] Flächen/Wege // Trolling in changesets

2018-04-04 Per discussione Hartmut Holzgraefe


On 04.04.2018 16:00, "Christian Müller" wrote:


Das Verkleben kannst du nicht beenden - was willst du in die
entstehenden Lücken tun?  Sind die dann nicht mehr Teil dieser
Welt?  Soll da Fugenmörtel rein?


es geht ja gerade um die Lücken. Die entstehen nicht erst dadurch
dass zwei Flächen nicht verbunden sind, sondern dadurch dass z-B.
zwischen zwei Feldern tatsächlich eine Lücke ist wenn da eine Straße
dazwischen verläuft.

Verklebt man Flächen und Wege dann verschwindet eine eigentlich
vorhandene Lücke.

Stoßen zwei Flächen dagegen tatsächlich direkt aneinander, zB.
ein Waldstück und eine Wiese, dann ist es kein Problem wenn diese
beiden sich eine Grenzlinie teilen. Darum geht es in diesem Thread
aber nicht, sondern konkret um das "verkleben" von Objekten 
unterschiedlicher Dimension: zweidimensionale Flächen mit

eindimensional erfassten Stra0en und Wegen.


Du kannst den Missstand mit den overlapping ways beenden,
indem du MP bildest, die sich der geometrisch korrekten
eingetragenen Flächengrenzen(-teile) bedienen.


Das verstehe ich nicht, das verkompliziert die Sache doch eher
noch mehr, wie wir an den immer wieder kaputt gehenden 
Verwaltungsgrenzen und Küstenlinien regelmäßig leidvoll erfahren ...


--
hartmut


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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

Vielleicht ist es besser zwischen

- allgemeinem "Verkleben" von Flächen

- "Verkleben" von Flächen mit highway=*

zu unterscheiden und zusätzlich zu erklären,
ob "Verkleben" nur die Bildung von Flächen
mit overlapping ways oder auch mit der Wie-
derverwendung von ways in MP meint.  Imho
wird derzeit sowohl das eine als auch das
andere darunter verstanden, d.h.

nicht verkleben == "Luft" zwischen Flächen


Gruß
cmuelle8

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

Re: [OSM-talk] QA bots commenting on changesets - your thoughts?

2018-04-04 Per discussione _ dikkeknodel

Hi Michał,

I can see value in making sure that mistakes are not accidentally introduced. 
However, I am not sure whether a bot like you describe is a wanted solution.

  *   I have concerns about false positives, when the bot considers an action 
as braking a connection and gives comment while the change is actually valid. 
This relates to what Martin brings in, false positives raise the noise level 
and the comments will therefore be ignored in the future. I don’t know what an 
acceptable level for false positives is, but there must be literature on it 
from psychology/computer sciences.
  *   Feedback by a bot as comment to a changeset is too late for maintaining 
data integrity, the mistake is already submitted to the database. The feedback 
should be given when trying to submit a changeset. I can imagine an 
implementation similar to what JOSM does for validation before submitting a 
dataset. This validation should then occur on the OSM server instead, or access 
to the changeset API should only be allowed for applications that have decent 
validation implemented. The second option is maybe preferable from a money 
perspective, since the calculations will be done locally and no server capacity 
is required. It will however put more requirements on hardware and software 
used to input data.

Cheers, dikkeknodel

Van: Martin Koppenhoefer
Verzonden: woensdag 4 april 2018 11:17
Aan: Michał Brzozowski
CC: osm
Onderwerp: Re: [OSM-talk] QA bots commenting on changesets - your thoughts?



2018-04-04 10:44 GMT+02:00 Michał Brzozowski 
>:
There's a bot in Poland that comments on changesets which break addresses (e.g. 
combining addr:place with addr:street), along with an explanation and links to 
forum topic.
What do you think about it? Are such bots useful or not?

while the example situation merits some kind of response, I am not sure if 
automated changeset comments are a good answer, because this will raise the 
noise level and very soon we will not find the needles in the comments haystack 
any more. Maybe the time has come for tags in changeset comments (bot=yes) ;-)
Cheers,
Martin

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

[OSRM-talk] Changing car.lua

2018-04-04 Per discussione Frank Durstewitz


Hi there.

I need to scale down the final speeds for all highways by ~ 25% for 
car-routability. The goal is to get 25% longer times in table and 
routing, independ if max_speed or calculated or...


What may the best place to do this?

Anybody?

TIA, Frank

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

[Talk-es] Complemento JOSM para Servicios Web de Catastro

2018-04-04 Per discussione Javier Sánchez Portero

Hola

Llevo tiempo dándole vueltas a alguna forma de hacer accesibles a todo el
mundo las fotos de fachada que proporciona Catastro y tenemos autorización
para usar [1]. Las fotos son un complemento a la observación sobre el
terreno útil para recoger números de portal, estado y tipo de edificios,
comprobar su número de plantas, si tiene balcones, forma del techo, si
aloja comercios o recursos de interés, ocasionalmente el nombre de la
calle, etc, etc.

Para acceder a una foto hace falta la referencia catastral de la parcela
donde está el edificio. Ahora mismo se puede hacer a través de un fichero
que genera el programa CatAtom2Osm [2], pero me gustaría que se pudiera
acceder más fácilmente desde JOSM.

Catastro proporciona unos servicios web públicos descritos en [3]. El que
necesitamos es la Consulta_RCCOOR [4], que devuelve la referencia catastral
a partir de las coordenadas. Este es un ejemplo de llamada al servicio [5]
y el enlace a la foto de fachada correspondiente [6].

El caso de uso sería que en JOSM, haciendo clic con el botón derecho en el
mapa, una opción del menú contextual permitiría obtener los datos de la
parcela (referencia catastral y dirección postal) y mostrar un enlace para
acceder a la foto.

Creo que no debe ser muy difícil de programar, aunque no tengo experiencia
con complementos de JOSM y me llevará un tiempo documentarme. Si alguien
quiere participar en el desarrollo que se ponga en contacto conmigo.

Saludos, Javier.

[1]
https://wiki.openstreetmap.org/wiki/ES:Fuentes_de_datos_potenciales_de_España#Fotos_de_fachada
[2] https://wiki.openstreetmap.org/wiki/ES:Catastro español/Importación de
edificios/Conversión de datos/Programa#Acceso_a_fotos_de_fachada
[3] http://www.catastro.meh.es/ws/Webservices_Libres.pdf
[4]
https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/OVCCoordenadas.asmx?op=Consulta_RCCOOR
[5]
https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/OVCCoordenadas.asmx/Consulta_RCCOOR?SRS=EPSG:4326_X=-16.3071274_Y=28.4273586
[6]
http://ovc.catastro.meh.es/OVCServWeb/OVCWcfLibres/OVCFotoFachada.svc/RecuperarFotoFachadaGet?ReferenciaCatastral=2251824CS7425S
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-de] Flächen/Wege // Trolling in changesets

> Sent: Wed, 4 Apr 2018 12:02:53 +0200 
> From: "Florian Lohoff" 
> To: Markus 
> Cc: talk-de@openstreetmap.org
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Eine Linie ist EIN Objekt und nicht 10 übereinander.

Eine Flächengrenze ist auch EIN Objekt, die 10 oder mehr oder
weniger Flächen begrenzt.

Das Verkleben kannst du nicht beenden - was willst du in die
entstehenden Lücken tun?  Sind die dann nicht mehr Teil dieser
Welt?  Soll da Fugenmörtel rein?

Du kannst den Missstand mit den overlapping ways beenden,
indem du MP bildest, die sich der geometrisch korrekten
eingetragenen Flächengrenzen(-teile) bedienen.


Gruß
cmuelle8

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

> Sent: Wed, 4 Apr 2018 08:07:26 +0200 
> From: "Florian Lohoff" 
> To: "Frederik Ramm" 
> Cc: talk-de@openstreetmap.org
> Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> > gibt nur Stress (denn jemand anders könnte mit gleichem Recht wieder
> > "ver-kleben").
> 
> Ich sehe das so ein bischen als eine fatale Entwicklung bei OSM. Es gibt
> stellen da traut sich keiner mehr dran. Die Neumapper aus Unwissenheit
> kleben noch zeugs dran und drüber. Sobald man verstanden hat was das
> alles ist geht der Durchschnittsmapper da nicht mehr dran - Sowas finde
> ich schade und ich empfinde das aufräumen als chance für neue mapper.

Vielen Dank für diesen amüsanten Beitrag, der sowohl historische Ent-
wicklungen, als auch mathematische Bezüge einmal mehr unter den Tisch
kehrt.

Das Verkleben ist alternativlos!  Die Frage ist natürlich WO man verklebt
_und_ welchen Detailgrad man anstrebt.

Wenn der Detailgrad hoch genug ist, trauen sich neue Mapper i.d.R. erstmal
nicht an ein Gebiet - da spielt es keine Rolle welche Methode angewandt
wurde.

/Weshalb/ wurde denn in der Vergangenheit verklebt?  Vielleicht weil die
technologische Entwicklung noch nicht so weit war, bzw. die technische
Ausstattung in der Breite eine andere, weniger leistungsfähige war?

Wer klebte, hat das i.d.R. aus /Effizienzgründen/ getan, denn damit
ließen sich oft mehrere parallele Linienzüge vermeiden.  Der topo-
logische Fehler, der damit in Kauf genommen wurde, war relativ klein
und bestand oft lediglich in vernachlässigten Straßengräben / -alleen
oder der Straßenbreite.

OSM war zudem anfangs als Straßenkarte ausgelegt, und schon jedesmal,
wenn es darum ging auch nur diese Straßen etwas detaillierter zu er-
fassen, beschäftigte sich jemand damit, wie man statt einer geometrischen
Lösung, eine tag-basierte verwenden könne - also, wie sich geographische
Lagedaten, die nicht näher interessieren, durch Schlagworte an den Linien-
zügen (ways) abstrahieren lassen.


Wenn ein Acker zwischen drei Straßen lag bzw. liegt und aus eben diesen
Effizienzgründen die Straßengräben vernachlässigt wurden, dann war eine
verklebte Version dieses Feldes evtl. geometrisch nicht völlig korrekt,
aber die Wiederverwendung dieser Straßen als Grenzen sowohl eine einfache,
sinnvolle und effiziente Ergänzung der Daten, um die Landnutzung der
Fläche anzuzeigen, die von diesen drei Straßen /begrenzt/ wurde.

Mit der Miniaturisierung rückte auch bei OSM das credo /less is more/
in den Hintergrund und Mapper begannen, die Details der Karte weniger
als Abstraktion und mehr als Abbild der Realität (lies: des Luft- oder
Satellitenbildes) wiederzugeben.

Wenn wir aber mehr Flächen in die DB eintragen, weil wir Detail, das
vorher durch den Mapping-Prozess wegabstrahiert wurde, wiedergeben
wollen, dann /verschieben/ und /vermehren/ wir lediglich die abge-
bildeten Flächengrenzen, die sich in der Realität oder von einem
Luftbild ableiten lassen.

Den Logos, dass eine Fläche an eine oder mehrere andere /grenzt/
lösen wir hingegen nicht auf (egal in welche Detailstufe wir gehen,
wir können immer wieder Flächen- oder auch Raumgrenzen finden bzw.
ableiten von dem was wir auf dieser Detailstufe vorfinden).

Es ist schlichtweg falsch, eine Fläche losgelöst von ihren Nachbar-
flächen zu betrachten, denn ihre Grenzen sind auch die der Nachbar-
flächen.  Oder anders gesagt, wir würden eine Fläche ohne die an-
grenzenden Nachbarn gar nicht als solche wahrnehmen können.


In OSM sind derzeit drei wesentliche Methoden beobachtbar, die ver-
suchen diesen Sachverhalt abzubilden:

1) ein Abschnitt (way) der sowohl Fläche A und B begrenzt, nimmt in der
Rolle 'outer' als Mitglied in den MP-Relationen für je A und B teil.

2) Für A und B werden zwei Wege (ways) benutzt (overlapping ways),
die sich eine Knotenfolge teilen (diese Folge wird in der Daten-
struktur für diese ways wiederholt)

3) Zwei ways mit voneinander unabhängigen Knoten bzw. -folgen werden
als Grenzen gezeichnet; die gemeinsame Flächengrenze wird durch zwei
Linien approximiert - mal ist Luft dazwischen, mal schneiden sich
Wegsegmente und die Flächen überlappen sich unabsichtlich etwas.


M.M.n. ist 1) die zu bevorzugende Variante, um Sachverhalte vor Ort
und am Boden abzubilden.  Es folgt den "best practices" im OSM Wiki.
Dort wird empfohlen, für jedes zu erfassende Objekt der Realität,
genau ein entsprechendes Objekt in der Datenbank anzulegen:

Die Flächengrenze gibt es genau einmal, also ist sie mit 1) auch nur
1x in der DB drin.  2) hat zwar noch keinen geometrischen Fehler,
aber die Rückübersetzung ist mehrdeutig:  sind zwei überlappende
Wege nun der gleiche Weg in der Realität oder nicht?  Sie könnten
schließlich auch in unterschiedlicher Höhe liegen (oder sich in
der Höhe kreuzen).

3) schließlich ist zwar oft (gern?) genutzt, aber sowohl wartungs-
technisch als auch geometrisch großer Mist, weil fehlerbehaftet.
Es entspricht quick-and-dirty Methoden, die man benutzt, wenn man

Re: [Talk-it] Import Dati regione Puglia

2018-04-04 Per discussione Francesco Piero Paolicelli

@luca solo brevemente.
i dataset di Viaggiare in Puglia e quelli della Digital Library verranno
adeguati agli standard CulturalON.
I portali Terra delle Gravine e Salentojonico.it hanno già i luoghi della
cultura e la digital library adeguati. La regione si uniformerà agli
standard Mibact quanto prima.
Mi sono solo portato il lavoro avanti su questi portali opendata perchè li
ho gestiti io.
Anzi, Viaggiare in Puglia importerà tutti i dati dei portali che ti ho
citato per accrescere il proprio database. Per esempio solo su Massafra
Viaggiare in puglia aveva 10-15 luoghi, sul portale terra delle gravine
solo su massafra ce ne sono 130.

buon import.
p

Il giorno 4 aprile 2018 15:06, Luca Riccardi  ha
scritto:

> @Federico,  grazie per la disponibilità, notificherò quanto detto a
> riguardo delle chiese (ma esteso in generale) a chi processerà gli import.
>
> @Francesco,  per ora è previsto il mapping dei beni culturali  presenti
> sui portali Viaggiare in puglia e Digital Library.
> Lo scopo principale è andare a mappare su OSM il bene culturale e la
> referenza annessa al portale di origine... questo è un tassello di un
> progetto più ampio!
> Ovviamente se si costituisse un "dizionario universale" raffinato dalla
> comunità, dove a prescindere dalla lingua, un determinato tipo di nodo
> viene mappato allo stesso modo (ad esempio chiesa prevederà sempre i tag
> evidenziati da Federico) a mio parere, potrebbe essere una cosa buona per
> tutti ed allo stesso tempo offrire un minimo di standard nel mapping* visto
> che adesso  mi è parso di capire che la scelta del tag dipende fortemente
> dal mapper.
>
> *ovviamente si tiene in considerazione che ci possano essere delle
> eccezioni.
>
> una curiosità... non ho ben chiaro se posso considerare "concessa"
> l'autorizzazione agli importo... o in caso negativo come continua l'iter! :)
>
> Il giorno 4 aprile 2018 14:32, Federico Cortese  ha
> scritto:
>
>> 2018-04-04 13:49 GMT+02:00 Luca Riccardi :
>>
>> > Anzi se posso approfittare: chi si occuperà del mapping della categoria
>> col
>> > tag (popolamento del dizionario) potrebbe contattarti in casi di dubbi o
>> > verificare se il mapping pensato è corretto?!
>>
>> Certamente
>>
>> > -chiese: dici che buona parte sono presenti (come poligoni  e non
>> semplici
>> > punti aventi il tag amenity=place_of_worship ), ma il sprovvisti del tag
>> > name?
>>
>> Sì, quando ho impostato l'import per i fabbricati ho assegnato
>> building=church + amenity=place_of_worship + religion=christian alle
>> chiese.
>> Quindi a parte quelle realizzate dopo il 2006 (data a cui risaliva
>> l'elaborazione della CTR), tutte le altre sono già presenti come
>> poligono edificato.
>> In fase di conflation, nell'eseguire l'import, abbiamo trasferito ai
>> nuovi fabbricati tutti i tag già presenti sui vecchi poligoni o sui
>> nodi.
>> Altre chiese sono state mappate successivamente all'import, ma
>> moltissime sono ancora senza nome, pertanto questo import potrebbe
>> permetterne il completamento.
>> Purtroppo nei dati della CTR si sono verificate anche interpretazioni
>> errate: mi è capitato di trovare chiese che in realtà sul posto erano
>> normali abitazioni (magari di forma particolare) oppure chiese
>> presenti sul posto che non erano state identificate come tali in fase
>> di elaborazione della CTR; si tratta comunque di casi rari.
>> Ecco un esempio di chiese senza nome nella mia zona:
>> http://overpass-turbo.eu/s/xzK
>>
>> Ciao,
>> Federico
>>
>> ___
>> 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-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-us] Whole-US Garmin Map update - 2018-04-02

2018-04-04 Per discussione Dave Hansen

These are based off of Lambertus's work here:

http://garmin.openstreetmap.nl

If you have questions or comments about these maps, please feel
free to ask.  However, please do not send me private mail.  The
odds are, someone else will have the same questions, and by
asking on the talk-us@ list, others can benefit.

Downloads:

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2018-04-02

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2018-04-02/kml/kml.html


FAQ



Why did you do this?

I wrote scripts to joined them myself to lessen the impact
of doing a large join on Lambertus's server.  I've also
cut them in large longitude swaths that should fit conveniently
on removable media.  

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2018-04-02

Can or should I seed the torrents?

Yes!!  If you use the .torrent files, please seed.  That web
server is in the UK, and it helps to have some peers on this
side of the Atlantic.

Why is my map missing small rectangular areas?

There have been some missing tiles from Lambertus's map (the
red rectangles),  I don't see any at the moment, so you may
want to update if you had issues with the last set.

Why can I not copy the large files to my new SD card?

If you buy a new card (especially SDHC), some are FAT16 from
the factory.  I had to reformat it to let me create a >2GB
file.

Does your map cover Mexico/Canada?

Yes!!  I have, for the purposes of this map, annexed Ontario
in to the USA.  Some areas of North America that are close
to the US also just happen to get pulled in to these maps.
This might not happen forever, and if you would like your
non-US area to get included, let me know. 

-- Dave


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

Re: [Talk-it] Import Dati regione Puglia

@Federico,  grazie per la disponibilità, notificherò quanto detto a
riguardo delle chiese (ma esteso in generale) a chi processerà gli import.

@Francesco,  per ora è previsto il mapping dei beni culturali  presenti sui
portali Viaggiare in puglia e Digital Library.
Lo scopo principale è andare a mappare su OSM il bene culturale e la
referenza annessa al portale di origine... questo è un tassello di un
progetto più ampio!
Ovviamente se si costituisse un "dizionario universale" raffinato dalla
comunità, dove a prescindere dalla lingua, un determinato tipo di nodo
viene mappato allo stesso modo (ad esempio chiesa prevederà sempre i tag
evidenziati da Federico) a mio parere, potrebbe essere una cosa buona per
tutti ed allo stesso tempo offrire un minimo di standard nel mapping* visto
che adesso  mi è parso di capire che la scelta del tag dipende fortemente
dal mapper.

*ovviamente si tiene in considerazione che ci possano essere delle
eccezioni.

una curiosità... non ho ben chiaro se posso considerare "concessa"
l'autorizzazione agli importo... o in caso negativo come continua l'iter! :)

Il giorno 4 aprile 2018 14:32, Federico Cortese  ha
scritto:

> 2018-04-04 13:49 GMT+02:00 Luca Riccardi :
>
> > Anzi se posso approfittare: chi si occuperà del mapping della categoria
> col
> > tag (popolamento del dizionario) potrebbe contattarti in casi di dubbi o
> > verificare se il mapping pensato è corretto?!
>
> Certamente
>
> > -chiese: dici che buona parte sono presenti (come poligoni  e non
> semplici
> > punti aventi il tag amenity=place_of_worship ), ma il sprovvisti del tag
> > name?
>
> Sì, quando ho impostato l'import per i fabbricati ho assegnato
> building=church + amenity=place_of_worship + religion=christian alle
> chiese.
> Quindi a parte quelle realizzate dopo il 2006 (data a cui risaliva
> l'elaborazione della CTR), tutte le altre sono già presenti come
> poligono edificato.
> In fase di conflation, nell'eseguire l'import, abbiamo trasferito ai
> nuovi fabbricati tutti i tag già presenti sui vecchi poligoni o sui
> nodi.
> Altre chiese sono state mappate successivamente all'import, ma
> moltissime sono ancora senza nome, pertanto questo import potrebbe
> permetterne il completamento.
> Purtroppo nei dati della CTR si sono verificate anche interpretazioni
> errate: mi è capitato di trovare chiese che in realtà sul posto erano
> normali abitazioni (magari di forma particolare) oppure chiese
> presenti sul posto che non erano state identificate come tali in fase
> di elaborazione della CTR; si tratta comunque di casi rari.
> Ecco un esempio di chiese senza nome nella mia zona:
> http://overpass-turbo.eu/s/xzK
>
> Ciao,
> Federico
>
> ___
> 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-it] Import Dati regione Puglia

2018-04-04 Per discussione Federico Cortese

2018-04-04 13:49 GMT+02:00 Luca Riccardi :

> Anzi se posso approfittare: chi si occuperà del mapping della categoria col
> tag (popolamento del dizionario) potrebbe contattarti in casi di dubbi o
> verificare se il mapping pensato è corretto?!

Certamente

> -chiese: dici che buona parte sono presenti (come poligoni  e non semplici
> punti aventi il tag amenity=place_of_worship ), ma il sprovvisti del tag
> name?

Sì, quando ho impostato l'import per i fabbricati ho assegnato
building=church + amenity=place_of_worship + religion=christian alle
chiese.
Quindi a parte quelle realizzate dopo il 2006 (data a cui risaliva
l'elaborazione della CTR), tutte le altre sono già presenti come
poligono edificato.
In fase di conflation, nell'eseguire l'import, abbiamo trasferito ai
nuovi fabbricati tutti i tag già presenti sui vecchi poligoni o sui
nodi.
Altre chiese sono state mappate successivamente all'import, ma
moltissime sono ancora senza nome, pertanto questo import potrebbe
permetterne il completamento.
Purtroppo nei dati della CTR si sono verificate anche interpretazioni
errate: mi è capitato di trovare chiese che in realtà sul posto erano
normali abitazioni (magari di forma particolare) oppure chiese
presenti sul posto che non erano state identificate come tali in fase
di elaborazione della CTR; si tratta comunque di casi rari.
Ecco un esempio di chiese senza nome nella mia zona:
http://overpass-turbo.eu/s/xzK

Ciao,
Federico

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

Re: [Talk-GB] YHA (England & Wales), Youth Hostel

2018-04-04 Per discussione Adam Snape

+1

Permission to add something to a map is certainly not the same as
permission to release information under the ODBL, we need that explicitly
stated.

Also, how are you going to locate the hostels? I'm assuming you're armchair
mapping, so how can you tell whether (or which) hostel mapped in OSM is the
relevant YHA one? Any information derived from the Google maps on the YHA
site is strictly unuseable, even with YHA's permission.

Kind regards,

Adam Snape

On 4 April 2018 at 13:08, Dan S  wrote:

> Hi
>
> "YHA (England & Wales)" would go in the "operator" field, not appended
> to the "name". (I'm not sure which you were suggesting.)
>
> I'm pretty sure that the loose permission (that you quote) is not
> technically enough to safely use the YHA's own list as a source of
> data for OSM, though it seems they're likely to be brodly in favour.
> With a bit more chat with them, and some reassurance that we're not
> intending to infringe on their copyrights, you can probably get
> something like an explicit permission to add the data to OSM under
> ODBL.
>
> Best
> Dan
>
>
> 2018-04-04 12:39 GMT+01:00 David Vere :
> > I've made an enquiry to YHA England & Wales and have been told that while
> >
> > "names of the individual hostels and YHA (England & Wales) as well as
> Youth
> > Hostel are all copyrighted”
> >
> > they are
> >
> > "happy for you to use the names on a map"
> >
> > and will even supply a current list.
> >
> > Is there any objection to my attaching the YHA hostel name and "YHA
> (England
> > & Wales)" to the hostels that are on openstreetmap.
> >
> > David
> >
> >
> >
> > ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
> >
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Import Dati regione Puglia

2018-04-04 Per discussione Francesco Piero Paolicelli

@luca per le masserie puoi anche importare molti dataset dai portali
comunali locali. come sai la Regione Puglia non ha un portale federato con
i Comuni per cui puoi vedere di prendere alcuni dati geografici sui portali
locali:

dati.comune.francavillafontana.br.it (trovi masserie)
dati.comune.galatone.le.it
dati.terradellegravine.eu (trovi anche le masserie ma anche luoghi della
cultura secondo l'ontologia CulturalON)
dati.comune.lecce.it

buon import.
piersoft

Il giorno 4 aprile 2018 13:49, Luca Riccardi  ha
scritto:

> @Federico, come hai correttamente intuito il dataset sugli Stabilimenti
> Balneari è stato escluso, come tutti quelli non direttamente popolati da
> innovapuglia... Saranno inclusi in un secondo momento dopo aver verificato
> la veridicità dei dati.
>
> Per i Tag: ti ringrazio per i suggerimenti!
>
> Per la maggior parte di quelli incontrati mi sono rifatto seguendo i tag
> più utilizzati nei nodi mappati. Banalmente ho cercato masseria su OSM ed
> ho visto che veniva usato il tag place=hamlet, ovviamente do sempre un
> occhio alla wiki per controllare la semantica del tag... ma mi son
> sbagliato!
> Anzi se posso approfittare: chi si occuperà del mapping della categoria
> col tag (popolamento del dizionario) potrebbe contattarti in casi di dubbi
> o verificare se il mapping pensato è corretto?!
>
> -chiese: dici che buona parte sono presenti (come poligoni  e non semplici
> punti aventi il tag amenity=place_of_worship ), ma il sprovvisti del tag
> name?
>
>
> -Dataset Ingressi grotte - rientrerà sicuramente nel piano di import!
> Infatti nella doc ho evidenziato che ne verranno aggiunti altri ( @Martin
> ad esempio, questo è un dataset con licenza IODL, quindi nella wiki
> specificherò che diversamente da quanto indicato nella sezione Dataset #n -
> Nome Dataset, la licenza è da considerarsi CC0)
>
> Luca
>
> Il giorno 4 aprile 2018 12:54, Federico Cortese  ha
> scritto:
>
>> 2018-04-04 10:07 GMT+02:00 Martin Koppenhoefer :
>> >
>> > in teoria si, in pratica sarebbe comunque interessante vedere le
>> divergenze
>> > su una mappa e dove ci sono i locali potrebbero dare un'occiata e vedere
>> > quanto siano buoni i dati (il fatto che la data 2016 è indicata non vuol
>> > dire che necessariamente tutti i dati contenuti nel dataset siano stati
>> > controllati in quel periodo, o sì?)
>> >
>>
>> Concordo pienamente e visto che sono un locale mi impegno a breve a
>> fare delle verifiche sui dataset nelle zone che conosco, come già
>> fatto in passato per i lidi balneari (sempre in questa discussione);
>> tra l'altro vedo giustamente che i lidi non sono stati inseriti nel
>> piano di import, viste le evidenti difformità riscontrate.
>>
>> Per quanto riguarda i tag proposti ho foti perplessità:
>>
>> Masserie ---> place = hamlet
>> Le masserie non hanno nulla a che vedere con un place=hamlet, si
>> riferiscono di solito al nome di edifici che storicamente hanno avuto
>> destinazione agricola, ma che attualmente possono essere adibiti a
>> vari usi differenti oppure in stato di abbandono.
>> In seguito all'import dei fabbricati di Puglia molti utenti hanno
>> aggiunto il nome della masseria al poligono generico building=yes; a
>> volte è stato aggiunto anche historic=farm o historic=building; a
>> volte per le masserie ancora utilizzate a scopi agricoli è stato
>> mappato il perimetro dell'attività con landuse=farmyard. Volendo
>> importare i nodi col nome della masseria bisognerebbe individuare un
>> tag adatto, ma personalmente credo sarebbe più opportuno associare il
>> nome all'edificio già esistente.
>> Questo un esempio della situazione attuale tra le provincie di
>> Brindisi e Taranto: http://overpass-turbo.eu/s/xzm
>>
>> Chiese e cattedrali > building = church, building = cathedral
>> Anche per le chiese sono state importate tutte le sagome degli
>> edifici, già taggate con amenity=place_of_worship, quindi si
>> tratterebbe di trasferire i nomi del dataset sulle chiese già mappate
>> come edificio, che non hanno ancora il tag name (ce ne sono
>> moltissime).
>>
>> Bed & breakfast ---> guest_house=bed_and_breakfast
>> Affittacamere ---> guest_house=bed_and_breakfast
>> Alloggi agrituristici ---> guest_house=agritourism
>> Per i tre casi sopra riportati andrebbe chiaramente aggiunto
>> tourism=guest_house, oltre a guest_house=*
>>
>> Villaggi turistici -- > place = village, tourism=*
>> Per i villaggi turistici il place=village è sicuramente sbagliato,
>> bisognerebbe usare solo il tag tourism; tourism=resort potrebbe essere
>> una soluzione anche se non viene renderizzato; su taginfo ne esistono
>> 498 occorrenze. Nella wiki
>> (https://wiki.openstreetmap.org/wiki/Tag%3Atourism%3Dresort) però se
>> ne sconsiglia l'uso a favore di leisure=resort
>> (https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dresort) che ha 4269
>> occorrenze. Non mi vengono in mente tag più adeguati, altrimenti si
>> potrebbe ripiegare sul

Re: [Talk-GB] YHA (England & Wales), Youth Hostel

2018-04-04 Per discussione Dan S

Hi

"YHA (England & Wales)" would go in the "operator" field, not appended
to the "name". (I'm not sure which you were suggesting.)

I'm pretty sure that the loose permission (that you quote) is not
technically enough to safely use the YHA's own list as a source of
data for OSM, though it seems they're likely to be brodly in favour.
With a bit more chat with them, and some reassurance that we're not
intending to infringe on their copyrights, you can probably get
something like an explicit permission to add the data to OSM under
ODBL.

Best
Dan


2018-04-04 12:39 GMT+01:00 David Vere :
> I've made an enquiry to YHA England & Wales and have been told that while
>
> "names of the individual hostels and YHA (England & Wales) as well as Youth
> Hostel are all copyrighted”
>
> they are
>
> "happy for you to use the names on a map"
>
> and will even supply a current list.
>
> Is there any objection to my attaching the YHA hostel name and "YHA (England
> & Wales)" to the hostels that are on openstreetmap.
>
> David
>
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>

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

Re: [Talk-cz] landuse v ceskych mestech

2018-04-04 Per discussione Pavel Machek

Ahoj!

> už jsem tu párkrát také psal z pohledu uživatele-programátora. Zkouším
> použití OSM pro renderování terénu pro letecké simulace (vrg.cz). OSM je
> krásně detailní balík dat, jehož vytvoření muselo dát v součtu strašně moc
> práce. Skláním se před tím. Ale vytváří ho jednotlivci, nadšenci bez
> uceleného vedení a systému kontroly (nestojí nad nimi zlý šéf :-), nebo QA
> oddělení). Z toho plynou rozdíly v kvalitě, detailu a často i způsobu
> tagování na různých místech. A pro nás programátory z toho plyne
> bohužel i

Jasny, kvalita bude kolisava. Ale to neznamena ze vy programatori
nemuzete pomoct s opravou.

> Co se týče chybějících Landuse: když koukám na tu Plzeň, řek bych, že to
> bude zase ten případ, kdy stroj nepochpí, člověk ano: tam, kde landuse neni
> určeno a zároveň tam stojí baráky, bude to pravděpodobně obytná zástavba.
> Škodovka a pivovar už jsou industrial. Dala by se vykreslit jako podklad
> hranice města v barvě obytné zástavby a terpve přes to polygony landuse.
> Jestli to ovšem v té VTM knihovně jde.

..takze samozrejme 2 moznosti, opravit to v kodu, a opravit to v
datech.

A ja bych doporucoval opravdu v datech, i kdyz se to opravi v kodu...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] Import Dati regione Puglia

@Federico, come hai correttamente intuito il dataset sugli Stabilimenti
Balneari è stato escluso, come tutti quelli non direttamente popolati da
innovapuglia... Saranno inclusi in un secondo momento dopo aver verificato
la veridicità dei dati.

Per i Tag: ti ringrazio per i suggerimenti!

Per la maggior parte di quelli incontrati mi sono rifatto seguendo i tag
più utilizzati nei nodi mappati. Banalmente ho cercato masseria su OSM ed
ho visto che veniva usato il tag place=hamlet, ovviamente do sempre un
occhio alla wiki per controllare la semantica del tag... ma mi son
sbagliato!
Anzi se posso approfittare: chi si occuperà del mapping della categoria col
tag (popolamento del dizionario) potrebbe contattarti in casi di dubbi o
verificare se il mapping pensato è corretto?!

-chiese: dici che buona parte sono presenti (come poligoni  e non semplici
punti aventi il tag amenity=place_of_worship ), ma il sprovvisti del tag
name?


-Dataset Ingressi grotte - rientrerà sicuramente nel piano di import!
Infatti nella doc ho evidenziato che ne verranno aggiunti altri ( @Martin
ad esempio, questo è un dataset con licenza IODL, quindi nella wiki
specificherò che diversamente da quanto indicato nella sezione Dataset #n -
Nome Dataset, la licenza è da considerarsi CC0)

Luca

Il giorno 4 aprile 2018 12:54, Federico Cortese  ha
scritto:

> 2018-04-04 10:07 GMT+02:00 Martin Koppenhoefer :
> >
> > in teoria si, in pratica sarebbe comunque interessante vedere le
> divergenze
> > su una mappa e dove ci sono i locali potrebbero dare un'occiata e vedere
> > quanto siano buoni i dati (il fatto che la data 2016 è indicata non vuol
> > dire che necessariamente tutti i dati contenuti nel dataset siano stati
> > controllati in quel periodo, o sì?)
> >
>
> Concordo pienamente e visto che sono un locale mi impegno a breve a
> fare delle verifiche sui dataset nelle zone che conosco, come già
> fatto in passato per i lidi balneari (sempre in questa discussione);
> tra l'altro vedo giustamente che i lidi non sono stati inseriti nel
> piano di import, viste le evidenti difformità riscontrate.
>
> Per quanto riguarda i tag proposti ho foti perplessità:
>
> Masserie ---> place = hamlet
> Le masserie non hanno nulla a che vedere con un place=hamlet, si
> riferiscono di solito al nome di edifici che storicamente hanno avuto
> destinazione agricola, ma che attualmente possono essere adibiti a
> vari usi differenti oppure in stato di abbandono.
> In seguito all'import dei fabbricati di Puglia molti utenti hanno
> aggiunto il nome della masseria al poligono generico building=yes; a
> volte è stato aggiunto anche historic=farm o historic=building; a
> volte per le masserie ancora utilizzate a scopi agricoli è stato
> mappato il perimetro dell'attività con landuse=farmyard. Volendo
> importare i nodi col nome della masseria bisognerebbe individuare un
> tag adatto, ma personalmente credo sarebbe più opportuno associare il
> nome all'edificio già esistente.
> Questo un esempio della situazione attuale tra le provincie di
> Brindisi e Taranto: http://overpass-turbo.eu/s/xzm
>
> Chiese e cattedrali > building = church, building = cathedral
> Anche per le chiese sono state importate tutte le sagome degli
> edifici, già taggate con amenity=place_of_worship, quindi si
> tratterebbe di trasferire i nomi del dataset sulle chiese già mappate
> come edificio, che non hanno ancora il tag name (ce ne sono
> moltissime).
>
> Bed & breakfast ---> guest_house=bed_and_breakfast
> Affittacamere ---> guest_house=bed_and_breakfast
> Alloggi agrituristici ---> guest_house=agritourism
> Per i tre casi sopra riportati andrebbe chiaramente aggiunto
> tourism=guest_house, oltre a guest_house=*
>
> Villaggi turistici -- > place = village, tourism=*
> Per i villaggi turistici il place=village è sicuramente sbagliato,
> bisognerebbe usare solo il tag tourism; tourism=resort potrebbe essere
> una soluzione anche se non viene renderizzato; su taginfo ne esistono
> 498 occorrenze. Nella wiki
> (https://wiki.openstreetmap.org/wiki/Tag%3Atourism%3Dresort) però se
> ne sconsiglia l'uso a favore di leisure=resort
> (https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dresort) che ha 4269
> occorrenze. Non mi vengono in mente tag più adeguati, altrimenti si
> potrebbe ripiegare sul generico tourism=hotel.
>
> PS Tra i diversi dataset c'è anche quello delle grotte naturali
> (http://www.dataset.puglia.it/dataset/catasti/resource/
> 7ba54f51-51dc-412a-bf59-dbe741062422),
> che avevo verificato essere molto ben posizionate (d'altra parte di
> solito le coordinate delle stesse sono rilevate sul posto). Si
> potrebbero aggiungere ai luoghi da importare.
>
> Ciao,
> Federico
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org

[Talk-GB] YHA (England & Wales), Youth Hostel

2018-04-04 Per discussione David Vere

I've made an enquiry to YHA England & Wales and have been told that while

"names of the individual hostels and YHA (England & Wales) as well as Youth
Hostel are all copyrighted”

they are

"happy for you to use the names on a map"

and will even supply a current list.

Is there any objection to my attaching the YHA hostel name and "YHA
(England & Wales)" to the hostels that are on openstreetmap.

David
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Next quarters project: Post Offices

2018-04-04 Per discussione Ed Loach

Thanks Robert.

I’ve been trying to track down some of the local unmapped ones.

This one I need to update (thanks to the ex-parish clerk who is regularly on a
pub quiz team with me confirming):

http://robert.mathmos.net/osm/postoffice/branch/24436

The actual location is the Memorial Club accessed from Harwich Road, but
probably closer to the Lodge Road postcode.

This one is proving more elusive:

http://robert.mathmos.net/osm/postoffice/branch/90116

It has a postcode in Ramsey village, has but the name of a different village.
I tried contacting the Ramsey & Parkeston Parish Clerk and they suggested I
contact Great Oakley, which suggests it isn’t in Ramsey at all (their village
hall is on Church Hill the other side of the A120).

However there is one in Great Oakley Village Hall on Monday and Thursday
mornings: http://www.great-oakley.co.uk/calendar.php which doesn’t seem to be
mapped or missing. This used to be Tuesday afternoons and Thursdays according
to this 2001 article when it first started:
http://www.gazette-news.co.uk/news/5478106.Great_Oakley___Use_or_lose__your_post_office_service/
Ah – and according to that article it was being run by the operator of Upper
Dovercourt Post Office, which is on a Main Road, but not the one in Ramsey
which is indicated by the post code. So I think that must be the one, only
3.5km away from where the post office think it is, and with different opening
hours.

I’ll tag it as you suggested, perhaps also with the id as mentioned in your
earlier email to help match them.

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

Re: [Talk-it] Import Dati regione Puglia

2018-04-04 Per discussione Federico Cortese

2018-04-04 10:07 GMT+02:00 Martin Koppenhoefer :
>
> in teoria si, in pratica sarebbe comunque interessante vedere le divergenze
> su una mappa e dove ci sono i locali potrebbero dare un'occiata e vedere
> quanto siano buoni i dati (il fatto che la data 2016 è indicata non vuol
> dire che necessariamente tutti i dati contenuti nel dataset siano stati
> controllati in quel periodo, o sì?)
>

Concordo pienamente e visto che sono un locale mi impegno a breve a
fare delle verifiche sui dataset nelle zone che conosco, come già
fatto in passato per i lidi balneari (sempre in questa discussione);
tra l'altro vedo giustamente che i lidi non sono stati inseriti nel
piano di import, viste le evidenti difformità riscontrate.

Per quanto riguarda i tag proposti ho foti perplessità:

Masserie ---> place = hamlet
Le masserie non hanno nulla a che vedere con un place=hamlet, si
riferiscono di solito al nome di edifici che storicamente hanno avuto
destinazione agricola, ma che attualmente possono essere adibiti a
vari usi differenti oppure in stato di abbandono.
In seguito all'import dei fabbricati di Puglia molti utenti hanno
aggiunto il nome della masseria al poligono generico building=yes; a
volte è stato aggiunto anche historic=farm o historic=building; a
volte per le masserie ancora utilizzate a scopi agricoli è stato
mappato il perimetro dell'attività con landuse=farmyard. Volendo
importare i nodi col nome della masseria bisognerebbe individuare un
tag adatto, ma personalmente credo sarebbe più opportuno associare il
nome all'edificio già esistente.
Questo un esempio della situazione attuale tra le provincie di
Brindisi e Taranto: http://overpass-turbo.eu/s/xzm

Chiese e cattedrali > building = church, building = cathedral
Anche per le chiese sono state importate tutte le sagome degli
edifici, già taggate con amenity=place_of_worship, quindi si
tratterebbe di trasferire i nomi del dataset sulle chiese già mappate
come edificio, che non hanno ancora il tag name (ce ne sono
moltissime).

Bed & breakfast ---> guest_house=bed_and_breakfast
Affittacamere ---> guest_house=bed_and_breakfast
Alloggi agrituristici ---> guest_house=agritourism
Per i tre casi sopra riportati andrebbe chiaramente aggiunto
tourism=guest_house, oltre a guest_house=*

Villaggi turistici -- > place = village, tourism=*
Per i villaggi turistici il place=village è sicuramente sbagliato,
bisognerebbe usare solo il tag tourism; tourism=resort potrebbe essere
una soluzione anche se non viene renderizzato; su taginfo ne esistono
498 occorrenze. Nella wiki
(https://wiki.openstreetmap.org/wiki/Tag%3Atourism%3Dresort) però se
ne sconsiglia l'uso a favore di leisure=resort
(https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dresort) che ha 4269
occorrenze. Non mi vengono in mente tag più adeguati, altrimenti si
potrebbe ripiegare sul generico tourism=hotel.

PS Tra i diversi dataset c'è anche quello delle grotte naturali
(http://www.dataset.puglia.it/dataset/catasti/resource/7ba54f51-51dc-412a-bf59-dbe741062422),
che avevo verificato essere molto ben posizionate (d'altra parte di
solito le coordinate delle stesse sono rilevate sul posto). Si
potrebbero aggiungere ai luoghi da importare.

Ciao,
Federico

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

Re: [OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO

2018-04-04 Per discussione marc marc

Ne serrait-il pas envisageable de demander un accès "spécial
pour contribuer à osm" sur le même modèle que l'accès à la BDOrtho ?

Le 04. 04. 18 à 12:32, Christian Quest a écrit :
> L'opendata pour la BD Topo, on n'y est pas encore... mais c'est une 
> piste de plus en plus sérieuse.
> 
> Le 4 avril 2018 à 11:14, Vincent Frison  > a écrit :
> 
> Hello,
> 
> Il semblerait que les choses doivent bientôt changer du côté de
> l'IGN et qu'ils vont devoir à (court?) terme devoir libérer leur
> données. Cela pourrait être fantastique pour OSM notamment pour leur
> BD TOPO. Quelqu'un aurait des infos plus précises à ce sujet ?
> 
> Dans le passé j'avais fait des scripts
>  pour importer les
> hauteurs de bâtiments à partir de diverses sources de données
> (notamment des combinaisons de MNT et MNS). C'était bien mais
> c'était assez laborieux et surtout ça ne concernait que quelques
> grandes villes (je l'avais fait que pour Paris, Nice et Montpellier).
> 
> Mais là avec cette BD TOPO on aurait tout le travail déjà fait (et
> bien fait j'espère).. et sur l'ensemble du pays !!!
> 
> Clairement si l'IGN passe ce jeu de données en Licence Ouverte ou
> ODbL (comme cela est préconisé par l'Etat) j'aimerais bien
> réutiliser mes scripts pour faire l'import dans OSM. Je parle
> uniquement des hauteurs de bâtiment, mais il y aura certainement un
> paquet d'autres choses à récupérer...
> 
> ++ Vincent.
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> 
> -- 
> 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: [Talk-ee] Rahvuspargid

2018-04-04 Per discussione Jaak Laineste


Selle topoloogilise puhtusega on nagu ta on - vaeva on üksjagu et seda saada, 
villa kogus on mõneti küsitav. 

Tegin siis kaks näidist: Matsalu https://www.openstreetmap.org/way/576248440 
 ja Vilsandi RP 
https://www.openstreetmap.org/relation/8178686 


Kaks asja jäid veel silma:

 1) Varasemad rahvuspargid - Lahemaa, Soomaa näivad olevat 
boundary=national_park + leisure=nature_reserve, mitte boundary=protected_area. 
Tundub et muidu ei renderdatagi, ja arutelu sellel teemal pole valmis 
https://github.com/gravitystorm/openstreetmap-carto/issues/603 
, kuigi suund 
nagu oleks ikka protected_area poole, sest iga kaitseala “national_park” 
nimetamine on liiga USAlik lähenemine.  

 2) Õigused. Andmed WFS metainfo kohaselt on CC-BY 4.0, ja selle kohta on selge 
juhis https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ 
 et tuleb eraldi 
luba küsida, see ei ole automaatselt kasutatav. Keda keskkonnaagentuuris 
kiusata sellega?



—
Jaak



> On 4 Apr 2018, at 12:56, Mihkel Oviir  wrote:
> 
> :D mul just oli sama mõte, et võtaks teema uuesti üles. Just kammisin EELISe 
> lehte, et kust ma need andmed kunagi leidsin.
> 
> 1) Märgenduse ettepanek on ok. Andmete päritolu tuleks ka lisada.
> 2) Piirjoonte ühtlustamise osas. Mina ei tea, on sel mõtet? Mis see reaalne 
> kasu on, et ei võiks lihtsalt importida nii nagu on? Ja edasi siis kui keegi 
> kuskil rannajoont õgvendab, siis juba viib soovi korral ise kokku. Mina ei 
> näpiks. Sama on ju ka haldusjaotusega, tihti järgib mingeid kraave jne. Et 
> mis siis õige on, kas jookseb mööda telge või tegelikult on piir kraavi 
> servas? Aga minu arvamus ainult.
> 3) Olemasolevad lk alad. Paar tükki on vahepeal juurde tulnud, Soomaa ja 
> Loodi. Seal peaks vaatama, kas olemasolev on üldse valiidne, kui ei ole, siis 
> asendama.
> 
> terv,
> Mihkel
> 
> 4. aprill 2018 12:42 kirjutas Jaak Laineste  >:
> 
> Võtaks veel korra seda kaitsealade teemat ülesse. 
> 
> Mis on olemas?
> 
> Kokku ma leian EELIS-est 
> ("WFS:https://gsavalik.envir.ee/geoserver/eelis/ows?version=2.0.0; 
> ", kr_kaitseala 
> tabel) ligi 900 polügoni, suuremad on 5 rahvusparki, 166 LKA-d ja 150 MKA-d 
> [1]. Lisaks suur hulk väiksemaid pargikesi jne. 
> 
> Küsimused, mis tekkisid:
> 
> 1) kuidas neid märgendada? Ma kasutaksin 
> https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area 
>  tag-e, 
> sinna Wiki lehe tabelisse tuleks lisada Eesti spetsiifika. Minu ettepanekud:
>   -  klassid (protect_class) võiksid olla RP=2, LKA=4, MKA=5. 
>   - Kaasa võiks EELIS-est võtta kr_kood tunnuse (tag: eelis:kr_kood, näiteks 
> KLO1000300 Matsalu puhul) 
>   - Tüüp läheb  protection_title alla : "rahvuspark", "looduskaitseala" ja 
> "maastikukaitseala", vastavalt. 
> 
> 2) kuidas piirjooni ühtlustada? See on juba põnevam probleem, sest Eestis on 
> üksjagu rannajoont ja kaitsealad järgivad sageli ka muid looduslikke objekte 
> nagu jõed/järved, mis on eri andmetes erinevas kohas. Näiteks proovisin 
> Vilsandi RP-d , mis on suhteliselt lihtne, sest piir on suuresti meres. 
> Ikkagi on seal mõned kilomeetrid rannajoont kokku vedada, vt [2]  Seal hall 
> joon on EELIS-e RP piir, värviline on OSM andmed, ja taga on metsanduse orto 
> JOSM-is. 
>  - Minu ettepanek: kasutada alati vana piirjoont OSM-is, ehk siis 
> eeldatavasti adminpiiridest pärit üsna täpset rannajoont, ja tekitada uued 
> polügonid/relatsioonid nende põhjal. Jooksvalt võib ju orto taustale võtta ja 
> rannajoont täpsustada enda aeropildi lugemise oskuse kohaselt. Kes oskab, 
> viib sujuvalt sisse ka Amsterdami nulli parandi :)
> 
> Paar vaadet:
> [1] kaitselad üldse 
> https://www.dropbox.com/s/u0ylv9wgrjrldlh/Screenshot%202018-04-04%2012.11.50.png?dl=0
>  
> 
> [2] rannajoon Vilsandi RP-l 
> https://www.dropbox.com/s/z1wvi9iu8pmh12k/Screenshot%202018-04-04%2011.50.26.png?dl=0
>  
> 
>   
> 
> 
>> On 11 Jan 2017, at 01:46, Teet Koitjärv > > wrote:
>> 
>> Tere.
>>  
>> Kõikide kaitsealade andmed on tegelikult digikujul EELIS-es 
>> (Keskkonnaregister – Eesti looduse infosüsteem) olemas. Sel teemal tasuks 
>> suhelda Keskkonnaagentuuri Eluslooduseosakonnaga 
>> (http://keskkonnaagentuur.ee/et/kontaktid 
>> ).
>>  
>>  
>> Tervitades
>>  
>> Teet Koitjärv
>>  
>>   <>
>> From: Jaak Laineste [mailto:j...@nutiteq.com ]

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

La jaune est typique d'un GPS "routier", qui fait de l'overshooting dans
les virages... c'est à dire qui tient compte des déplacements précédents
pour "lisser".
C'est un phénomène qui ne date pas d'hier, il y a plus de 10 ans, ça me
posait des problèmes pour les contrôles de vols dans les compétitions de
parapente !

Exemple:
http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577#19/47.13163/-1.50767

Sur le rond point le vert ne déborde pas, par contre, le passage sous
l'autoroute n'est pas lissé comme le jaune (et tant mieux, si on a le DOP
indiqué).

Pour moi c'est le vert qui s'en sort le mieux, correspond à des mesures
réelles et pas extra/inter-polées... tout le bénef d'un GPS dédié et où ces
extrapolation peuvent être en principe désactivées (ou plutôt activées à la
demande et pas l'inverse).



Le 3 avril 2018 à 18:41, Stéphane Péneau  a
écrit :

> Hello,
>
> Alors, qui était qui dans ce test ?
>
> Je rappelle les protagonistes :
> - Smartphone Sony Xperia Ray
> - Smartphone HTC One mini
> - Tablette Nexus 9
> - Tablette Nvidia Tablet Shield K1
> - Navspark GL.
>
> Et les résultats :
> http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577
>
> On peut facilement éliminer la trace bleue (Xperia Ray), la orange (HTC
> One mini), ainsi que la rouge (Nvidia Shield).
> Il nous reste la trace verte et la trace jaune.
>
> Je le rappelais, ce n'est pas vraiment la position absolue qui comptait
> dans ce test, mais la façon dont les traces se décalaient en cas
> d'obstacles alors que le déplacement reste rectiligne. Une antenne sur le
> toit est censée mieux capter les signaux des satellites, et pouvoir plus
> facilement discriminer les signaux ayant subi un rebond.
> Voici quelques pistes où les traces vertes restent parallèles alors que
> les jaunes dérivent :
> http://www.stemani.fr/public/gnss/gnss1.jpg
> http://www.stemani.fr/public/gnss/gnss2.jpg
> http://www.stemani.fr/public/gnss/gnss3.jpg
> C'est encore plus flagrant sur cette dernière capture :
> http://www.stemani.fr/public/gnss/gnss4.jpg
>
> La trace jaune est la tablette Nexus 9, et la verte est bien le récepteur
> Navspark GL avec l'antenne sur le toit.
>
> Si quelqu'un souhaite regarder de plus près, par exemple dans Josm, les
> voici :
> http://www.stemani.fr/public/gnss/test_gnss.zip
>
> Stéphane
>
>
>
>
>
> Le 28/03/2018 à 00:59, Stéphane Péneau a écrit :
>
>> Le 28/03/2018 à 00:10, Francois Gouget a écrit :
>>
>>> J'aurais tendance à dire qu'il n'y en a pas un pour rattraper les
>>> autres. Mais peut-être ai-je raté les points importants ?
>>>
>> Normalement, si tu décoches au fur et à mesure les traces qui te semble
>> les moins bonnes pour qu'elles ne perturbent plus l'affichage, tu devrais
>> trouver assez facilement celle qui vient de l'antenne sur le toit.
>> J'avoue qu'avoir quelques niveaux de zooms supplémentaires, ça aide, mais
>> umap semble limité sur ce point.
>>
>> Je donnerai la réponse dans quelques jours.
>>
>> ___
>> 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
>



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

Re: [OSM-talk-be] Conflation OpenData Brussels

2018-04-04 Per discussione marc marc

Hello,

Le 04. 04. 18 à 11:39, Glenn Plas a écrit :
> On 04-04-18 11:23, eMerzh wrote:
>> i was thinking more like a map  of missings schools
>> with ideally a "one-click" import ( 1 feature by 1 feature)
> 
> If I take the school case , it's do-able to take all schools out from OSM, 
> put them in a postGIS table and then do the same with Urbis data

for this usecase, it's maybe usefull to use Osmose.
it allow to build a list of false-positive and can also be used
for survey for ex in Vespucci.
it allow also to follow upstream update.

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

Re: [OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO

L'opendata pour la BD Topo, on n'y est pas encore... mais c'est une piste
de plus en plus sérieuse.

Le 4 avril 2018 à 11:14, Vincent Frison  a écrit :

> Hello,
>
> Il semblerait que les choses doivent bientôt changer du côté de l'IGN et
> qu'ils vont devoir à (court?) terme devoir libérer leur données. Cela
> pourrait être fantastique pour OSM notamment pour leur BD TOPO. Quelqu'un
> aurait des infos plus précises à ce sujet ?
>
> Dans le passé j'avais fait des scripts
>  pour importer les hauteurs
> de bâtiments à partir de diverses sources de données (notamment des
> combinaisons de MNT et MNS). C'était bien mais c'était assez laborieux et
> surtout ça ne concernait que quelques grandes villes (je l'avais fait que
> pour Paris, Nice et Montpellier).
>
> Mais là avec  cette BD TOPO on aurait tout le travail déjà fait (et bien
> fait j'espère).. et sur l'ensemble du pays !!!
>
> Clairement si l'IGN passe ce jeu de données en Licence Ouverte ou ODbL
> (comme cela est préconisé par l'Etat) j'aimerais bien réutiliser mes
> scripts pour faire l'import dans OSM. Je parle uniquement des hauteurs de
> bâtiment, mais il y aura certainement un paquet d'autres choses à
> récupérer...
>
> ++ Vincent.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

Hi Markus,

On Wed, Apr 04, 2018 at 10:45:34AM +0200, Markus wrote:
> Hallo Frederik, hallo Florian,

> Wenn eine bestimmte Ausprägung aber zu Chaos und Entropie führt,
> und dies zunehmend unbewältigbar scheint und zu entsprechendem Frust und
> Verlust von Motivation und Mitarbeit führt, dann läuft etwas falsch.
> Und wir sollten uns dem rechtzeitig und grundlegend annehmen.

Das ist so meine Wahrnehmung. Eine Zeitlang habe ich mal jede Changeset
durchgesehen hier in der Gegend und habe dann gerne kommentiert - Oft
kamen dann wirklich dinge zurück wie "Ich weiss gar nicht wie du das
meinst" oder "Das bekomme ich nicht hin - kanst du das reparieren."

Mich hat das zur Überzeugung gebracht das ich mit 10 Jahren OSM einfach
auch "Betriebsblind" bin - Ich gehe immer so davon aus das was ich da
verstanden habe und hin bekomme doch jeder hinbekommen kann. Dem ist
aber eben nicht so. Ich kann so ein Liniengewirr im Kopf sortieren und
nach und nach auseinanderdröseln - Der Neumapper kann das nicht - Der
"malt" drüber oder gibt auf.

Deshalb bin ich auch so ein großer Freund davon das verkleben zu
beenden. Für mich sorgt das für klarere Strukturen in den Daten die
jeder verstehen kann. Eine Linie ist EIN Objekt und nicht 10
übereinander.

> Also bleiben nur drei Möglichkeiten:
> entweder zurück zum alten falschen Zustand,
> oder alles auseinanderdröseln - und mit viel Aufwand darauf achten, dass
> ich keine Verschlimmbesserungen erzeuge - und dann meine (kleine)
> Verbesserung einzutragen,
> oder frustriert den verschlimmbesserten Zustand hochladen (in der
> vermutlich irrigen Annahme, dass das da schon "irgendjemand" der sich
> besser auskennt/mehr Zeit hat wieder aufräumt).

Ich empfinde das oft als "trauen". Jemand mit breitem Kreuz der einfach
dann auch mal "Delete" drückt und dann sich zur not auch mal anmachen
lässt was das soll.

> Auch für mich ist das sehr hilfreich!
> In einer aufgeräumten Gegend helfe ich gern und ergänze Neues :-)
> 
> _Ursachen_
> Parallel zu solchen Aufräum-Aktionen sollten wir uns überlegen, was die
> Ursachen für dieses Chaos sind und wie wir verhindern können, dass nicht
> noch mehr Chaos erzeugt wird.
> 
> Mögliche Ursachen für "Verkleben":
> 1. Mappen für den Renderer
>(damit die Karte "schön" wird, keine "weissen Flächen" hat)
> 2. fehlende Regeln (weil irgendwie verpönt?) für Best Practice
>und fehlende Erklärungen, warum man Dinge so und nicht anders macht

Das mit den best practices geht ja heute schon "schief". Es gibt ja so
ein how-to in dem u.a. erklärt wird das man bei parallelen Linien die
Nodes auch entsprechend immer in allen Linien hat - Klappt auch nur
begrenzt.

> Viel wäre schon geholfen, wenn wir folgende Regeln hätten:
> 
> - Linien nicht mit Flächen verbinden
> - Linien nur mit gleichartigen Linien verbinden
> - Flächen nur mit gleichartigen Flächen verbinden
> - Ausnahmen genau und nachvollziehbar definieren und begründen
> - für Linien in Flächen die Hierarchie definieren
> - für Flächen in Flächen die Hierarchie definieren
> 
> (und das genau zu definieren ist vermutlich ziemlich viel Arbeit,
> inhaltlich - und vermutlich auch emotional)

Ich finde das hat was mit Vorbildfunktion zu tun. In einer Gegend in der
es sehr aufgeräumt ist wird typischerweise sehr aufgeräumt weiter
gemappt. In den gegenden wo eh alles übereinander ist wird halt genau so
weiter gemacht. 

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away

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

Re: [Talk-ee] Rahvuspargid

2018-04-04 Per discussione Mihkel Oviir

:D mul just oli sama mõte, et võtaks teema uuesti üles. Just kammisin
EELISe lehte, et kust ma need andmed kunagi leidsin.

1) Märgenduse ettepanek on ok. Andmete päritolu tuleks ka lisada.
2) Piirjoonte ühtlustamise osas. Mina ei tea, on sel mõtet? Mis see reaalne
kasu on, et ei võiks lihtsalt importida nii nagu on? Ja edasi siis kui
keegi kuskil rannajoont õgvendab, siis juba viib soovi korral ise kokku.
Mina ei näpiks. Sama on ju ka haldusjaotusega, tihti järgib mingeid kraave
jne. Et mis siis õige on, kas jookseb mööda telge või tegelikult on piir
kraavi servas? Aga minu arvamus ainult.
3) Olemasolevad lk alad. Paar tükki on vahepeal juurde tulnud, Soomaa ja
Loodi. Seal peaks vaatama, kas olemasolev on üldse valiidne, kui ei ole,
siis asendama.

terv,
Mihkel

4. aprill 2018 12:42 kirjutas Jaak Laineste :

>
> Võtaks veel korra seda kaitsealade teemat ülesse.
>
> Mis on olemas?
>
> Kokku ma leian EELIS-est ("WFS:https://gsavalik.envir.e
> e/geoserver/eelis/ows?version=2.0.0&", kr_kaitseala tabel) ligi 900
> polügoni, suuremad on 5 rahvusparki, 166 LKA-d ja 150 MKA-d [1]. Lisaks
> suur hulk väiksemaid pargikesi jne.
>
> Küsimused, mis tekkisid:
>
> 1) kuidas neid *märgendada*? Ma kasutaksin https://wiki.openstreetmap.org
> /wiki/Tag:boundary%3Dprotected_area tag-e, sinna Wiki lehe tabelisse
> tuleks lisada Eesti spetsiifika. Minu ettepanekud:
>   -  klassid (protect_class) võiksid olla RP=2, LKA=4, MKA=5.
>   - Kaasa võiks EELIS-est võtta kr_kood tunnuse (tag: eelis:kr_kood,
> näiteks KLO1000300 Matsalu puhul)
>   - Tüüp läheb  protection_title alla : "rahvuspark", "looduskaitseala" ja
> "maastikukaitseala", vastavalt.
>
> 2) kuidas *piirjooni* ühtlustada? See on juba põnevam probleem, sest
> Eestis on üksjagu rannajoont ja kaitsealad järgivad sageli ka muid
> looduslikke objekte nagu jõed/järved, mis on eri andmetes erinevas kohas.
> Näiteks proovisin Vilsandi RP-d , mis on suhteliselt lihtne, sest piir on
> suuresti meres. Ikkagi on seal mõned kilomeetrid rannajoont kokku vedada,
> vt [2]  Seal hall joon on EELIS-e RP piir, värviline on OSM andmed, ja taga
> on metsanduse orto JOSM-is.
>  - Minu ettepanek: kasutada alati vana piirjoont OSM-is, ehk siis
> eeldatavasti adminpiiridest pärit üsna täpset rannajoont, ja tekitada uued
> polügonid/relatsioonid nende põhjal. Jooksvalt võib ju orto taustale võtta
> ja rannajoont täpsustada enda aeropildi lugemise oskuse kohaselt. Kes
> oskab, viib sujuvalt sisse ka Amsterdami nulli parandi :)
>
> Paar vaadet:
> [1] kaitselad üldse https://www.dropbox.com/s/u0ylv9wgrjrldlh/Screenshot%
> 202018-04-04%2012.11.50.png?dl=0
> [2] rannajoon Vilsandi RP-l https://www.dropbox.com/s/
> z1wvi9iu8pmh12k/Screenshot%202018-04-04%2011.50.26.png?dl=0
>
>
> On 11 Jan 2017, at 01:46, Teet Koitjärv  wrote:
>
> Tere.
>
> Kõikide kaitsealade andmed on tegelikult digikujul EELIS-es
> (Keskkonnaregister – Eesti looduse infosüsteem) olemas. Sel teemal tasuks
> suhelda Keskkonnaagentuuri Eluslooduseosakonnaga (
> http://keskkonnaagentuur.ee/et/kontaktid).
>
>
> Tervitades
>
> Teet Koitjärv
>
>
> *From:* Jaak Laineste [mailto:j...@nutiteq.com ]
> *Sent:* Tuesday, January 10, 2017 9:50 PM
> *To:* OpenStreetMap Estonia 
> *Subject:* Re: [Talk-ee] Rahvuspargid
>
>
> Käsitsi neid ei kaardista, seega kuni ruumi-avaandmete x-teed pole
> leiutatud ja realiseeritud, siis ei jää tõesti muud üle kui andmed ümber
> tõsta.
>
> Kui piirjooned saab kokku viia (seal vist rannajoont peaks
> korduvkasutama?), ja kontrollida kas mõni pole juhtumisi juba olemas, siis
> ma pole vastu.
>
>
> Jaak
>
>
>
> On 10 Jan 2017, at 18:45, Mihkel Oviir  wrote:
>
> Tõstaks teema üles uuesti. Kes on poolt, et looduskaitsealad võiks
> massimpordiga ära lahendada? Nokin Eidapere ümbrust ja laadisin
> keskkonnaregistrist hoiualade andmed alla (bljää, küll andis otsida, kuidas
> saaks looduskaitse andmeid andmetena kätte), aga tundus ikkagi kuidagi
> mõtetu see käsitsi ühekaupa sisestamine.
>
> terv,
> Mihkel
>
> Muidu näeb selline välja:
>
>
>  
>
> 1. september 2016 15:38 kirjutas Mihkel Oviir :
>
> Kas administratiivse(ma)te piiridega ei saaks kasutada olemasolevaid
> andmeid ja mass-importi? Igasugune käsitsi külapiiride nikerdamine on asi,
> mis on mulle küll vastukarva, sest see viib kiirelt väärandmeteni. Sama ka
> looduskaitsealadega.
>
> Mihkel
>
> 1. september 2016 15:29 kirjutas Jaak Laineste :
>
> Piinlik lugu soode, rabade ja looduskaitsealade maal Eestis: siin on OSM-i
> kohaselt vaid üks rahvuspark! Viktoriini küsimus: milline?
>
> Ja tõsisem küsimus: kas ülejäänud on kuhugi kadunud, või pole olnudki? Ja
> kes parandab selle vea?
>
>
> Jaak
>
>
>
>
>
>
>
>
>
> ___
> Talk-ee mailing list
> Talk-ee@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ee
>
>
>
>
>

Re: [OSM-talk] Help me build an OSM Community Index

2018-04-04 Per discussione Paul Norman


On 3/31/2018 5:25 AM, Bryan Housel wrote:
a `.geojson` file to describe where the region where it is active. 
 (multiple resources can share a .geojson file)


I'm having trouble figuring out what a sensible region is for the 
meetups in Vancouver and the Pacific Northwest.


Our meetups are along the coast, but I don't believe there are any other 
meetups for a few hundred km as you go inland. Closer to home, I'd 
consider Chilliwack part of our region in many ways, but it's 100km from 
there to our normal meeting place. This makes it too far to suggest, 
because it's a 90+ minute drive. Where would I cut it off?


Going up and down the coast, we have a different problem. Vancouver, 
South-Central Salish Sea, and Seattle all share a meetup organization, 
and have overlap in members. The boundaries here are fuzzy.


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

Re: [Talk-it] Import Dati regione Puglia

- Da questo punto di vista, i dataset vengono aggiornati periodicamente
quindi, la buona norma prevede che, i dati contenuti siano allineati con la
realtà al momento dell'aggiornamento.
 Per quanto riguarda i dataset di innovapuglia, mi garantirono della
veridicità dei dati, poiché sono dati gestiti dalla A all Z da loro.

- Licenza: dovrebbe valere la licenza indicata nel dataset, quindi CC0. :)

Luca


Il giorno 4 aprile 2018 09:35, Alessandro  ha scritto:

> Il 03/04/2018 22:52, Martin Koppenhoefer ha scritto:
>
>>
>>
>> la conflation dei punti dove ci sono dubbi non deve necessariamente
>> essere fatta subito, si potrebbe togliere gli oggetti dall’import e creare
>> delle liste / mappe e chiedere ai mappatori locali di verificare. Se i dati
>> sono del 2016 è probabile che in alcuni punti il dataset è già superato
>> rispetto alla realtà, e sarebbe grave sovrascrivere dati attuali con dati
>> vecchi tramite import (è vero che comunque si importeranno alcuni oggetti
>> non più esistenti, tutti quelli chiusi dal 2016 ad oggi, ma questo per me
>> dovrebbe decidere la comunità locale, se il guadagno fosse abbastanza
>> grande da poter accettare qualche danno collaterale).
>>
>>
> Inserendo questi dati dubbi in una lista si potrebbero poi confrontare con
> le date di aggiornamento dei POI su OSM, se questi sono antecedenti al 2016
> potrebbero essere caricati.
>
> Alessandro Ale_zena_IT
>
>
> ___
> 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-ee] Rahvuspargid

2018-04-04 Per discussione Jaak Laineste


Võtaks veel korra seda kaitsealade teemat ülesse. 

Mis on olemas?

Kokku ma leian EELIS-est 
("WFS:https://gsavalik.envir.ee/geoserver/eelis/ows?version=2.0.0; 
", kr_kaitseala 
tabel) ligi 900 polügoni, suuremad on 5 rahvusparki, 166 LKA-d ja 150 MKA-d 
[1]. Lisaks suur hulk väiksemaid pargikesi jne. 

Küsimused, mis tekkisid:

1) kuidas neid märgendada? Ma kasutaksin 
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area 
 tag-e, 
sinna Wiki lehe tabelisse tuleks lisada Eesti spetsiifika. Minu ettepanekud:
  -  klassid (protect_class) võiksid olla RP=2, LKA=4, MKA=5. 
  - Kaasa võiks EELIS-est võtta kr_kood tunnuse (tag: eelis:kr_kood, näiteks 
KLO1000300 Matsalu puhul) 
  - Tüüp läheb  protection_title alla : "rahvuspark", "looduskaitseala" ja 
"maastikukaitseala", vastavalt. 

2) kuidas piirjooni ühtlustada? See on juba põnevam probleem, sest Eestis on 
üksjagu rannajoont ja kaitsealad järgivad sageli ka muid looduslikke objekte 
nagu jõed/järved, mis on eri andmetes erinevas kohas. Näiteks proovisin 
Vilsandi RP-d , mis on suhteliselt lihtne, sest piir on suuresti meres. Ikkagi 
on seal mõned kilomeetrid rannajoont kokku vedada, vt [2]  Seal hall joon on 
EELIS-e RP piir, värviline on OSM andmed, ja taga on metsanduse orto JOSM-is. 
 - Minu ettepanek: kasutada alati vana piirjoont OSM-is, ehk siis eeldatavasti 
adminpiiridest pärit üsna täpset rannajoont, ja tekitada uued 
polügonid/relatsioonid nende põhjal. Jooksvalt võib ju orto taustale võtta ja 
rannajoont täpsustada enda aeropildi lugemise oskuse kohaselt. Kes oskab, viib 
sujuvalt sisse ka Amsterdami nulli parandi :)

Paar vaadet:
[1] kaitselad üldse 
https://www.dropbox.com/s/u0ylv9wgrjrldlh/Screenshot%202018-04-04%2012.11.50.png?dl=0
 

[2] rannajoon Vilsandi RP-l 
https://www.dropbox.com/s/z1wvi9iu8pmh12k/Screenshot%202018-04-04%2011.50.26.png?dl=0
 

  


> On 11 Jan 2017, at 01:46, Teet Koitjärv  wrote:
> 
> Tere.
>  
> Kõikide kaitsealade andmed on tegelikult digikujul EELIS-es 
> (Keskkonnaregister – Eesti looduse infosüsteem) olemas. Sel teemal tasuks 
> suhelda Keskkonnaagentuuri Eluslooduseosakonnaga 
> (http://keskkonnaagentuur.ee/et/kontaktid 
> ).
>  
>  
> Tervitades
>  
> Teet Koitjärv
>  
>   <>
> From: Jaak Laineste [mailto:j...@nutiteq.com] 
> Sent: Tuesday, January 10, 2017 9:50 PM
> To: OpenStreetMap Estonia 
> Subject: Re: [Talk-ee] Rahvuspargid
>  
>  
> Käsitsi neid ei kaardista, seega kuni ruumi-avaandmete x-teed pole leiutatud 
> ja realiseeritud, siis ei jää tõesti muud üle kui andmed ümber tõsta.
>  
> Kui piirjooned saab kokku viia (seal vist rannajoont peaks korduvkasutama?), 
> ja kontrollida kas mõni pole juhtumisi juba olemas, siis ma pole vastu.
>  
>  
> Jaak
>  
>  
> On 10 Jan 2017, at 18:45, Mihkel Oviir  > wrote:
>  
> Tõstaks teema üles uuesti. Kes on poolt, et looduskaitsealad võiks 
> massimpordiga ära lahendada? Nokin Eidapere ümbrust ja laadisin 
> keskkonnaregistrist hoiualade andmed alla (bljää, küll andis otsida, kuidas 
> saaks looduskaitse andmeid andmetena kätte), aga tundus ikkagi kuidagi mõtetu 
> see käsitsi ühekaupa sisestamine.
>  
> terv,
> Mihkel
>  
> Muidu näeb selline välja:
>  
>  
>  
>  
> 1. september 2016 15:38 kirjutas Mihkel Oviir  >:
> Kas administratiivse(ma)te piiridega ei saaks kasutada olemasolevaid andmeid 
> ja mass-importi? Igasugune käsitsi külapiiride nikerdamine on asi, mis on 
> mulle küll vastukarva, sest see viib kiirelt väärandmeteni. Sama ka 
> looduskaitsealadega.
>  
> Mihkel
>  
> 1. september 2016 15:29 kirjutas Jaak Laineste  >:
> Piinlik lugu soode, rabade ja looduskaitsealade maal Eestis: siin on OSM-i 
> kohaselt vaid üks rahvuspark! Viktoriini küsimus: milline?
>  
> Ja tõsisem küsimus: kas ülejäänud on kuhugi kadunud, või pole olnudki? Ja kes 
> parandab selle vea?
>  
>  
> Jaak
>  
>  
>  
>  
>  
> 
>  
>  
> ___
> Talk-ee mailing list
> Talk-ee@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ee 
> 
>  
>  
> ___
> Talk-ee mailing list
> Talk-ee@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ee 
> 
>  
> ___
> Talk-ee mailing list
>

Re: [OSM-talk-be] Conflation OpenData Brussels

2018-04-04 Per discussione Glenn Plas

On 04-04-18 11:23, eMerzh wrote:
> Thanks for your responses :)
> and yeah i totally agree that an import is probably not a good idea,
> but i was thinking more like a map  of missings schools or streets
> without surface  (with one in the dataset)
> and with ideally a "one-click" import ( 1 feature by 1 feature)

The datasets are fine in a  'supporting' role, like the cases you
mention above.   If I take the school case , it's do-able to take all
schools out from OSM, put them in a postGIS table and then do the same
with Urbis data , you can then throw postGIS functions on those 2 to
extract a diff.  You need some common ground and postGIS is perfect for
that.   Since BXL dataset is quite small compaired to GRB, that work
will be fast.   If I want to reprocess the GRB data the way it's
processed now, we are talking about 6 hours of crunching, and if
something isn't quite right you need to start over.

In any case, you probably need to verify every school to see if it still
exists.  There are quite a few schools in Brussels according to OSM :
http://overpass-turbo.eu/s/xzj

Glenn

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

Re: [OSM-talk-be] Conflation OpenData Brussels

2018-04-04 Per discussione eMerzh

Thanks for your responses :)
and yeah i totally agree that an import is probably not a good idea,
but i was thinking more like a map  of missings schools or streets without
surface  (with one in the dataset)
and with ideally a "one-click" import ( 1 feature by 1 feature)



2018-04-04 11:04 GMT+02:00 Glenn Plas :

> On 03-04-18 21:22, eMerzh wrote:
> > Hi all :)
> >
> > I'm just discovering the data sets that are in
> > http://opendatastore.brussels/  (brussels region)
> > and some of them might be really interesting for osm.
> > Like :
> > - school list
> > - streets surfaces
> > - 3d buildings
> > - parkings
> > - transports stop poles
> > and much more
> >
> > , but I was wondering if there was an "easy" way to do the
> > conflation... automatically or semi-manually ...
> > for now the only way I see is to transform data, put them in a
> > postgis  then doing all the work manually... but...
> > ** there must be a better way **
> > no?
>
> hi,
>
> Concerning the 3D buildings and Street surfaces, I know for sure that
> this is data coming from Urbis which is a high quality dataset but even
> that doesn't justify importing it into OSM without human review.
>
> I've been considering to include the Urbis dataset in my tool but I have
> to keep the focus on GRB, once that is launched I will point my
> attention to Urbis data.  The tool basically does what you state, it
> imports it into postgis and makes it easy to export into JOSM directly
> and translated to OSM model as good as I/IT can.  The urbis source data
> model will work quite well with my transform procedure and tools
>
> Not all the data there is GIS oriented either.  But a lot is scatttered
> around, for example, on the parking subject we are dealing with 12
> different datasets, there are sets who represent the access to the
> parkings , which in OSM would be a simple access tag on another set.
> Here you will have to combine the parking sets and do process the data ,
> do the Q/A , handle the exceptions etc.  You cannot consider this job
> easy and straightforward, it's going to be painful instead.
>
> Also, the more I look at the data, the more errors and problems I see,
> I've been working with GRB data for a long time and only last week I
> contacted Marc to verify if he also noticed that there seems to be an
> "addressing" problem in the transformed data where housenumbers seem to
> be messed up in certain cases, and he confirmed this.  And that is a
> "new" problem, aka: something which slipped my attention for a good year
> now...  I traced this down to the .dbf data files containing the address
> data, so it's a source problem we need to mitigate. (it's not
> impossible, it's just more work)
>
> That's just to say, preparing this data is so much work, I've been
> working on that part alone -daily- for the last 3 months.   It all
> starts with quality.  I've been using GRB 3D data set as an aid to
> determine building types, that is about as far as I want to go for
> several reasons.  the GRB set (non 3D) is a lot better maintained than
> 3D grb, which kinda looks like an experiment (that went quite well)
>
> That is also the big issue I have with all the imports in the wild
> without data analysis, scrutiny and Q/A work.  We do notice people are
> just importing the shape files straight into OSM without understanding
> the problems related to this.  Antwerp for example is huge mistake
> happening,  Antwerp used to be quite empty on buildings but now it looks
> like it's just a flat import of GRB shapefile data (1)
>
> Also Yves has done his homework on VILLO and STIB data, I've seen what
> he had to deal with those datasets, I totally agree with his conclusion
> that this isn't just a simple: "hey it's gis data, that's good enough"
> and that bulk imports like the one that fucked up Antwerp (but makes it
> look good on the map) should be avoided.
>
> I work at CIBG/CIRB so I can determine the source of certain datasets if
> required and talk to people here to get to know where they are coming
> from (not all datasets are from government sources, a lot are from
> customers of CIBG/CIRB )
>
> In short, I would be careful and not import in bulk, the schools you
> could probably merge/verify with OSM in a few days manually.  I would
> choose the latter.  There is more time spent on automating than you(and
> definitely me too)  would think at first glance.
>
> Glenn
>
>
>
> [1]   Diff tool :
> http://tiles.grbosm.site/slide/app/index.html#15/51.2091/4.4226
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk] QA bots commenting on changesets - your thoughts?

2018-04-04 10:44 GMT+02:00 Michał Brzozowski :

> There's a bot in Poland that comments on changesets which break addresses
> (e.g. combining addr:place with addr:street), along with an explanation and
> links to forum topic.
> What do you think about it? Are such bots useful or not?
>


while the example situation merits some kind of response, I am not sure if
automated changeset comments are a good answer, because this will raise the
noise level and very soon we will not find the needles in the comments
haystack any more. Maybe the time has come for tags in changeset comments
(bot=yes) ;-)

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

[OSM-talk-fr] Import des hauteurs de bâtiment depuis la BD TOPO

2018-04-04 Per discussione Vincent Frison

Hello,

Il semblerait que les choses doivent bientôt changer du côté de l'IGN et
qu'ils vont devoir à (court?) terme devoir libérer leur données. Cela
pourrait être fantastique pour OSM notamment pour leur BD TOPO. Quelqu'un
aurait des infos plus précises à ce sujet ?

Dans le passé j'avais fait des scripts
 pour importer les hauteurs de
bâtiments à partir de diverses sources de données (notamment des
combinaisons de MNT et MNS). C'était bien mais c'était assez laborieux et
surtout ça ne concernait que quelques grandes villes (je l'avais fait que
pour Paris, Nice et Montpellier).

Mais là avec  cette BD TOPO on aurait tout le travail déjà fait (et bien
fait j'espère).. et sur l'ensemble du pays !!!

Clairement si l'IGN passe ce jeu de données en Licence Ouverte ou ODbL
(comme cela est préconisé par l'Etat) j'aimerais bien réutiliser mes
scripts pour faire l'import dans OSM. Je parle uniquement des hauteurs de
bâtiment, mais il y aura certainement un paquet d'autres choses à
récupérer...

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

Am 4. April 2018 um 08:07 schrieb Florian Lohoff :

>
> Wenn ich da was auf mache endet das meistens in einer Stundenlangen
> Aufräumaktion mit Verkleinerung der Landuses. Korrektur der Lage und
> Topologie. Dann plumpsen da noch so 10-20 Bugs raus mit dingen die sich
> aus den Luftbildern nicht klären lassen.
>


+1, "zu große" Landuses sind auch ein Thema. M.E. spricht nichts dagegen,
landuses so klein wie möglich/nötig zu mappen, z.B. Straßenflächen
möglichst nicht mit reinzunehmen. Das ist zum einen detaillierter, und zum
anderen viel leichter bearbeitbar und besser durchschaubar.



>
> Und man findet halt auch nur beim Entkleben schon Tonnen an Bugs. Wo
> dadurch das das jetzt 10 Jahre da so rumgelungert hat diverse Mapper
> einfach drüber oder daneben die selben dinge noch einmal eingezeichnet
> haben weil eben kein Objekt mit der Form da war. Doppelt und Dreifache
> Gebäude, Tracks, Hauszufahrten weil die eben mit beliebigen Flächen
> verbunden, deformiert wurden und dann erneut eingezeichnet.
>


ja, Hecken und Zäune, die mitten durch Flächen zu gehen scheinen, weil das
Feld bis zu Straßenmitte gezeichnet ist.


>
> Ich sehe das so ein bischen als eine fatale Entwicklung bei OSM. Es gibt
> stellen da traut sich keiner mehr dran. Die Neumapper aus Unwissenheit
> kleben noch zeugs dran und drüber. Sobald man verstanden hat was das
> alles ist geht der Durchschnittsmapper da nicht mehr dran - Sowas finde
> ich schade und ich empfinde das aufräumen als chance für neue mapper.



+1. Was schon da ist, färbt auch wieder auf neue Beiträge ab, weil man sich
als neuer Mapper normalerweise erstmal umsieht, was bereits wie gemacht ist
(im eigenen Umfeld, das man kennt).

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

Re: [OSM-talk-be] Conflation OpenData Brussels

2018-04-04 Per discussione Glenn Plas

On 03-04-18 21:22, eMerzh wrote:
> Hi all :)
>
> I'm just discovering the data sets that are in
> http://opendatastore.brussels/  (brussels region)
> and some of them might be really interesting for osm.
> Like :
> - school list
> - streets surfaces
> - 3d buildings
> - parkings
> - transports stop poles
> and much more
>
> , but I was wondering if there was an "easy" way to do the
> conflation... automatically or semi-manually ...
> for now the only way I see is to transform data, put them in a
> postgis  then doing all the work manually... but...
> ** there must be a better way **
> no?

hi,

Concerning the 3D buildings and Street surfaces, I know for sure that
this is data coming from Urbis which is a high quality dataset but even
that doesn't justify importing it into OSM without human review.

I've been considering to include the Urbis dataset in my tool but I have
to keep the focus on GRB, once that is launched I will point my
attention to Urbis data.  The tool basically does what you state, it
imports it into postgis and makes it easy to export into JOSM directly
and translated to OSM model as good as I/IT can.  The urbis source data
model will work quite well with my transform procedure and tools

Not all the data there is GIS oriented either.  But a lot is scatttered
around, for example, on the parking subject we are dealing with 12
different datasets, there are sets who represent the access to the
parkings , which in OSM would be a simple access tag on another set. 
Here you will have to combine the parking sets and do process the data ,
do the Q/A , handle the exceptions etc.  You cannot consider this job
easy and straightforward, it's going to be painful instead.

Also, the more I look at the data, the more errors and problems I see, 
I've been working with GRB data for a long time and only last week I
contacted Marc to verify if he also noticed that there seems to be an
"addressing" problem in the transformed data where housenumbers seem to
be messed up in certain cases, and he confirmed this.  And that is a
"new" problem, aka: something which slipped my attention for a good year
now...  I traced this down to the .dbf data files containing the address
data, so it's a source problem we need to mitigate. (it's not
impossible, it's just more work)

That's just to say, preparing this data is so much work, I've been
working on that part alone -daily- for the last 3 months.   It all
starts with quality.  I've been using GRB 3D data set as an aid to
determine building types, that is about as far as I want to go for
several reasons.  the GRB set (non 3D) is a lot better maintained than
3D grb, which kinda looks like an experiment (that went quite well)

That is also the big issue I have with all the imports in the wild
without data analysis, scrutiny and Q/A work.  We do notice people are
just importing the shape files straight into OSM without understanding
the problems related to this.  Antwerp for example is huge mistake
happening,  Antwerp used to be quite empty on buildings but now it looks
like it's just a flat import of GRB shapefile data (1)

Also Yves has done his homework on VILLO and STIB data, I've seen what
he had to deal with those datasets, I totally agree with his conclusion
that this isn't just a simple: "hey it's gis data, that's good enough" 
and that bulk imports like the one that fucked up Antwerp (but makes it
look good on the map) should be avoided.

I work at CIBG/CIRB so I can determine the source of certain datasets if
required and talk to people here to get to know where they are coming
from (not all datasets are from government sources, a lot are from
customers of CIBG/CIRB )

In short, I would be careful and not import in bulk, the schools you
could probably merge/verify with OSM in a few days manually.  I would
choose the latter.  There is more time spent on automating than you(and
definitely me too)  would think at first glance.

Glenn

[1]   Diff tool : 
http://tiles.grbosm.site/slide/app/index.html#15/51.2091/4.4226

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

2018-04-04 Per discussione Markus

Hallo Frederik, hallo Florian,

>> Eigentlich hatten wir diesbezüglich immer eine Art "Waffenstillstand" ->> 
>> wer neu mappt, sucht sich aus, welchen Stil er möchte, und wer eine>>
Gegend "generalüberholt", kann das vielleicht auch tun, aber
"ent-kleben>> um des Ent-klebens willen", d.h. wenn gar keine neue
Information>> dazukommt ausser dass halt ent-klebt wird, das sollte man
nicht tun, das>> gibt nur Stress (denn jemand anders könnte mit gleichem
Recht wieder>> "ver-kleben").
Auch ich bin sehr für Freiheit.
Denn Freiheit ist eine wesentliche Voraussetzung für Kreativität.

Wenn eine bestimmte Ausprägung aber zu Chaos und Entropie führt,
und dies zunehmend unbewältigbar scheint und zu entsprechendem Frust und
Verlust von Motivation und Mitarbeit führt, dann läuft etwas falsch.
Und wir sollten uns dem rechtzeitig und grundlegend annehmen.

Neu-Mapper sind nach meiner Erfahrung immer begeistert und motiviert.
Und gleichzeitig erschlagen von der Komplexität unseres Systems.
Sie wollen es gern "richtig" machen, scheitern aber an fehlender oder
schwer zu findender oder unverständlicher Information im Wiki.

Florian, damit beschreibst Du ein grösseres Übel ziemlich treffend:

> endet meistens in einer stundenlangen Aufräumaktion 
> Und man findet beim Entkleben schon Tonnen an Bugs.
> Es gibt Stellen da traut sich keiner mehr dran. 
> Die Neumapper aus Unwissenheit kleben noch Zeugs dran und drüber.

Auch ich habe zunehmend weniger Lust, etwas einzutragen :-(
Kaum verschiebe ich etwas, ändern sich die damit verklebten Objekte.
Sich kongruent überlagernde aber nicht identische Objekte sind ein
ähnliches Übel.

Also bleiben nur drei Möglichkeiten:
entweder zurück zum alten falschen Zustand,
oder alles auseinanderdröseln - und mit viel Aufwand darauf achten, dass
ich keine Verschlimmbesserungen erzeuge - und dann meine (kleine)
Verbesserung einzutragen,
oder frustriert den verschlimmbesserten Zustand hochladen (in der
vermutlich irrigen Annahme, dass das da schon "irgendjemand" der sich
besser auskennt/mehr Zeit hat wieder aufräumt).

> ich empfinde das Aufräumen als Chance für neue Mapper.

Auch für mich ist das sehr hilfreich!
In einer aufgeräumten Gegend helfe ich gern und ergänze Neues :-)

_Ursachen_
Parallel zu solchen Aufräum-Aktionen sollten wir uns überlegen, was die
Ursachen für dieses Chaos sind und wie wir verhindern können, dass nicht
noch mehr Chaos erzeugt wird.

Mögliche Ursachen für "Verkleben":
1. Mappen für den Renderer
   (damit die Karte "schön" wird, keine "weissen Flächen" hat)
2. fehlende Regeln (weil irgendwie verpönt?) für Best Practice
   und fehlende Erklärungen, warum man Dinge so und nicht anders macht

Viel wäre schon geholfen, wenn wir folgende Regeln hätten:

- Linien nicht mit Flächen verbinden
- Linien nur mit gleichartigen Linien verbinden
- Flächen nur mit gleichartigen Flächen verbinden
- Ausnahmen genau und nachvollziehbar definieren und begründen
- für Linien in Flächen die Hierarchie definieren
- für Flächen in Flächen die Hierarchie definieren

(und das genau zu definieren ist vermutlich ziemlich viel Arbeit,
inhaltlich - und vermutlich auch emotional)

Mit herzlichem Gruss,
Markus

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

Re: [OSM-talk-fr] Import station essence

2018-04-04 Per discussione Marc Gemis

A lot of fuel stations can be use 24/7 with a bank card
-->
A lot of fuel stations can be used 24/7 with a bank card

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

[OSM-talk] QA bots commenting on changesets - your thoughts?

2018-04-04 Per discussione Michał Brzozowski

There's a bot in Poland that comments on changesets which break addresses
(e.g. combining addr:place with addr:street), along with an explanation and
links to forum topic.

What do you think about it? Are such bots useful or not?

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

Am 3. April 2018 um 00:59 schrieb Frederik Ramm :

> Eigentlich hatten wir diesbezüglich immer eine Art "Waffenstillstand" -
> wer neu mappt, sucht sich aus, welchen Stil er möchte, und wer eine
> Gegend "generalüberholt", kann das vielleicht auch tun,



d.h. er hätte schreiben sollen, "ich bin gerade dabei, mein Umfeld
'generalzuüberholen' und in diesem Zug entklebe ich auch Flächen seitlich
von Straßen mit deren Mittellinie?



> aber "ent-kleben
> um des Ent-klebens willen", d.h. wenn gar keine neue Information
> dazukommt ausser dass halt ent-klebt wird, das sollte man nicht tun,



sofern man die "entklebten" Flächenränder nicht in der Straßenmitte lässt
sondern an den tatsächlichen Rand der Fläche schiebt, kommt ja
grundsätzlich Information dazu.

Ich hatte Florian so verstanden, dass es ihm lieber wäre, anstatt weiterhin
in einem Kompromiss zu leben, wo man keine klare Empfehlung abgibt, mal
wieder ein allgemeines Meinungsbild einzuholen, ob man sich vielleicht
diesesmal auf eine Lösung einigen kann, und da überwiegend nicht verklebt
wird, böte sich dieser Stil an.
Das "Verkleben" hat m.E. vorwiegend Nachteile: es ist eine Generalisierung
die ab einem bestimmten Maßstab nicht mehr funktioniert, die Flächen werden
dadurch zu groß abgebildet, Objekte auf der Straße und in der Nähe
fälschlicherweise in die Fläche eingeschlossen (z.B. Briefkästen und
Telefonzellen), und im Gegenzug erhält man eine "aufgeräumtere" Karte
(sofern nicht alles detailliert gemappt ist, sieht es sauberer aus, weil
keine "Restflächen" zurückbleiben, wobei unterschlagen wird, dass es diese
Restflächen meistens auch wirklich gibt). Es wurde auch schon angeführt sei
es vermeintlich topologisch richtiger, weil die Straßen ja wirklich bis zur
Fläche gingen, aber gleichzeitig verbindet man so (die gegenüberliegenden)
Flächen miteinander, die eigentlich durch die Straßenfläche getrennt sind,
fügt also einen Topologiefehler hinzu. Letzteres sind zugegebenermaßen
Definitions- und Interpretationsfragen, wenn man es aufwändig haben will,
kann man die Topologiesachen analysieren und berechnen (z.B. annehmen, dass
Straßen immer eine Ausdehnung haben müssen, und sich nie auf den seitlichen
landuses und anderen Flächen befinden können, was aber nicht unbedingt
weltweit immer stimmen muss) , aber die fehlende Information der wirklichen
Flächengrenze kann man nur raten.

Vor allem  stehen dem Probleme beim Editing gegenüber (umständlicher und
zeitraubender, Verfeinerungen einzubauen), die leicht zu Folgefehlern
(falsche und ggf. fehlende Verbindungen im Graph) führen, und der erhöhte
Bearbeitungsaufwand lässt manchen Mapper schon vor dem Start davor
zurückschrecken, überhaupt Verfeinerungen zu mappen.

Falls man keine Einigung erzielt könnte man auch intensiver landuse=highway
(i.e. Straßenflächen, -parzellen) oder auch area:highway=* (befahrbare
Straßenfläche) mappen, dann würde sich das Problem von selbst lösen. ;-)

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

Re: [Talk-it] Import Dati regione Puglia

2018-04-04 9:35 GMT+02:00 Alessandro :

> Inserendo questi dati dubbi in una lista si potrebbero poi confrontare con
> le date di aggiornamento dei POI su OSM, se questi sono antecedenti al 2016
> potrebbero essere caricati.




in teoria si, in pratica sarebbe comunque interessante vedere le divergenze
su una mappa e dove ci sono i locali potrebbero dare un'occiata e vedere
quanto siano buoni i dati (il fatto che la data 2016 è indicata non vuol
dire che necessariamente tutti i dati contenuti nel dataset siano stati
controllati in quel periodo, o sì?)

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

Re: [OSM-talk-be] Conflation OpenData Brussels

2018-04-04 Per discussione Yves bxl-forever

Hello,

Let aside the technical aspect—this is a good question and I hope somebody will 
be able to give valuable advice—I believe that some datasets in government open 
data portals are poisoned with either incorrect or outdated data.  Importing 
them into OSM could make some damage without extensive review by humans with 
local knowledge.

Here are two examples I am familiar with, and for which I believe bulk imports 
should be avoided.

1) Villo! stations: name tag is an odd upper-case string concatenating the name 
and the address, and capacity seems to be missing in the source data (but can 
be manually retrieved for the website by clicking each station one by one).

2) STIB/MIVB stops: not only the GTFS export replaces the name of the stop with 
a truncated and upper-case version of it—to cope with limitations of their 
real-time app on smaller devices—but the lat/lon values refer to the stop 
position… in OSM it must be a node that is part of the way used by the route 
(and they do not match).  Incidently, STIB/MIVB does not maintain any database 
with the location of the stop *posts*; the only place in the world where this 
information exists is in OSM.

Have a nice day.
Yves

On Tue, 3 Apr 2018 21:22:33 +0200
eMerzh  wrote:

> Hi all :)
> 
> I'm just discovering the data sets that are in
> http://opendatastore.brussels/  (brussels region)
> and some of them might be really interesting for osm.
> Like :
> - school list
> - streets surfaces
> - 3d buildings
> - parkings
> - transports stop poles
> and much more
> 
> , but I was wondering if there was an "easy" way to do the conflation...
> automatically or semi-manually ...
> for now the only way I see is to transform data, put them in a postgis
> then doing all the work manually... but...
> ** there must be a better way **
> no?

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

Re: [OSM-talk-be] Conflation OpenData Brussels

2018-04-04 Per discussione Marc Gemis

Hallo,

The more automated the conflation is done, the more strict the import
guidelines have to be followed.

There are a number of tools that come to my mind:

- JOSM with OpenData & Conflation plugins
- Glenn's tool for GRB building import might be adaptable for your use
- Ilya Zverik's conflation tool that is currently used for the gas
station import  preparation.
- The tool the UK community uses to prepare their quarterly projects.
They did something around schools last last year, where the goal was
that the participants solved the conflation problem in their local
area.

Conflation won't work easily for

- road surfaces: you might have to split existing OSM ways representing streets
- 3D buildings: It's very likely that their model does not match the
simple 3D model of OSM. Their is a separate repository for 3D models
now.
- PT should be rather complete. Contact Polyglot to see whether the
data is so different from what we "imported" already


IMHO, manual conflation is preferable. Given the many mismatches
between any company/government data set and the reality, a check by a
human is necessary.

regards

m

p.s. I can look up more information or contact info for particular
tools if you want.

On Tue, Apr 3, 2018 at 9:22 PM, eMerzh  wrote:
> Hi all :)
>
> I'm just discovering the data sets that are in
> http://opendatastore.brussels/  (brussels region)
> and some of them might be really interesting for osm.
> Like :
> - school list
> - streets surfaces
> - 3d buildings
> - parkings
> - transports stop poles
> and much more
>
> , but I was wondering if there was an "easy" way to do the conflation...
> automatically or semi-manually ...
> for now the only way I see is to transform data, put them in a postgis  then
> doing all the work manually... but...
> ** there must be a better way **
> no?
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [Talk-it] Import Dati regione Puglia

2018-04-04 Per discussione Alessandro


Il 03/04/2018 22:52, Martin Koppenhoefer ha scritto:



la conflation dei punti dove ci sono dubbi non deve necessariamente essere 
fatta subito, si potrebbe togliere gli oggetti dall’import e creare delle liste 
/ mappe e chiedere ai mappatori locali di verificare. Se i dati sono del 2016 è 
probabile che in alcuni punti il dataset è già superato rispetto alla realtà, e 
sarebbe grave sovrascrivere dati attuali con dati vecchi tramite import (è vero 
che comunque si importeranno alcuni oggetti non più esistenti, tutti quelli 
chiusi dal 2016 ad oggi, ma questo per me dovrebbe decidere la comunità locale, 
se il guadagno fosse abbastanza grande da poter accettare qualche danno 
collaterale).



Inserendo questi dati dubbi in una lista si potrebbero poi confrontare 
con le date di aggiornamento dei POI su OSM, se questi sono antecedenti 
al 2016 potrebbero essere caricati.


Alessandro Ale_zena_IT

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

[Talk-es] Índice de la Comunidad OSM

2018-04-04 Per discussione Javier Sánchez Portero

Hola

Bryan Housel ha iniciado un proyecto para crear una base de datos de
recursos disponibles para la Comunidad OpenStreetMap por regiones.

https://lists.openstreetmap.org/pipermail/dev/2018-March/030191.html

La idea es que esta base puede ser utilizada por distintas aplicaciones,
los editores iD, Potlatch, Vespucci, etc, para proporcionar enlaces a los
usuarios para obtener ayuda o contactar con las comunidades locales de la
zona que estén editando.

Es una idea similar al repositorio común de fuentes de datos que hace que
las mismas capas de imágenes estén disponibles por regiones para todos esos
programas.

Ya he incluido el canal de Telegram OSMes, me gustaría añadir esta lista,
el canal de IRC y las salas de Matrix. Para poder hacerlo es necesario
incluir el nombre y el correo de un administrador en cada recurso.

La/las administradoras por favor mándeme su correo para incluirlos.

Si quieres colaborar con el proyecto, las traducciones están disponibles en

https://www.transifex.com/openstreetmap/id-editor/

Si alguien quiere añadir al listado algún recurso local y necesita ayuda,
se puede poner en contacto conmigo.

Saludos, Javier
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-de] Flächen/Wege // Trolling in changesets