Re: [OSM-talk-fr] Comment tagger cette ex-départementale à une voie ?

2019-05-20 Per discussione Shohreh
marc marc wrote
> mais juste pour rappeler le sens des tag d'accès sur les way : celui de
> correspondre à des panneaux imposant une restriction légale. donc y-a-t-il
> un panneau à l'entrée ?

Bon à savoir.

D'un côté, il y avait le nouveau — et bien pratique — panneau "Impasse sauf
piéton/vélo", et de l'autre… j'ai pas pensé à regarder :-p

Je ne vais donc rien mettre en "access" et ajouter les deux barrières
anti-2RM… et les routeurs aviseront en conséquence.

Merci à tous.




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


[OSM-talk-fr] Fwd: [Francophone] GéoDataDays 2019 ! - 2 et 3 juillet, Arras

2019-05-20 Per discussione Jean-Christophe Becquet
Bonjour,

Un événement vu sur la liste de l'OSGeo-fr qui pourrait intéresser des
gens ici.

Bonne journée

JCB


 Message transféré 
Sujet : [Francophone] GéoDataDays 2019 ! - 2 et 3 juillet, Arras
Date :  Mon, 20 May 2019 11:44:30 +0200
De :Secrétariat OSGeo-Fr 
Répondre à :roelandtn@gmail.com, Francophone local chapter
discussions 
Pour :  francoph...@lists.osgeo.org



Bonjour à toutes et tous,

L'OSGeo-fr est partenaire des GéoDataDays 2019 ! les 2 et 3 juillet
prochains à Arras.
Nous vous invitons à en découvrir le programme et à nous rejoindre sur
notre stand lors de l'évènement.

Découvrez les premiers grands témoins :

* Valéria FAURE-MUNTIAN, députée de la Loire, fera un point d’étape des
actions proposées dans son rapport sur les données "souveraines".
* Jacques LÉVY est géographe politique, lauréat du Prix Vautrin-Lud
2018. Il reviendra sur son dernier ouvrage "Théorie de la justice
spatiale – Géographies du juste et de l’injuste".
* Gaël MUSQUET  Hacker citoyen impliqué dans l'anticipation et la
prévention des catastrophes naturelles, fondateur d’OpenStreetMap (OSM)
France et président de Hackers Against Natural Disasters (HAND).

Programme:

Deux grands débats pour réinventer le secteur
Les bouleversements de la géodata, ses acteurs, ses services en 2
chapitres, avec un panel d'experts et grands témoins !

Des moments forts pour les plateformes territoriales
* Le lancement de Géo2France, la nouvelle géoplateforme des Hauts-de-France
* Les 10 ans du Réseau des CRIGEs !

Deux thèmes au cœur de l'actualité
* Ouverture et business des géodata : les enjeux qui pèsent sur la santé
* Géointelligence ou l'information géographique en action : les défis de
la sécurité

Trois grands défis à relever pour demain
* Un SIG 3D sinon rien !
* Quand la géodata fait foi...
* Développement économique, marketing territorial, défense du commerce local

Deux ateliers pratiques pour repartir avec de bonnes idées
* Gouvernance, transversalité et spécificités des géodata : se faire
entendre !
* Plan Corps de Rue Simplifié (PCRS) : s'organiser et avancer

Des vitrines sur des innovations technologiques pour suivre les
dernières tendances
* Un espace exposant pour valoriser les savoir-faire, les solutions… du
secteur
* Des ateliers sponsors (Neogeo Technologies, Géofoncier…) pour
découvrir des pépites technologiques
* Un festival de Géo-innovations pour promouvoir votre projet

Des animations pour favoriser le Networking... et garder le sourire !
* Chaque matin, prévoyez vos pitchs et vos cartes de visite pour le
Meet-Up des GéoDataDays.
* Lors du cocktail dînatoire du 2 juillet, continuez à développer votre
réseau... dans un cadre surprenant : le cloître de l’abbaye bénédictine
Saint-Vaast qui accueille le musée des Beaux-Arts d'Arras !


Pensez à vous inscrire rapidement (hébergement limité !):
https://www.geodatadays.fr/inscription

*Secrétariat de l’OSGéo-FR* : http://osgeo.asso.fr/

secretar...@osgeo.asso.fr 

Cécile Le Calvez: Secrétaire

Nicolas Roelandt: secrétaire adjoint

___
Francophone mailing list
francoph...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/francophone___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSRM-talk] Interested in consulting for unique routing use case

2019-05-20 Per discussione Frederik Ramm
Hi,

On 5/20/19 17:18, Zannah Pierce wrote:
> We are looking to find GIS/routing experts who can help solve the
> problem of routing over custom, dynamic data. 

"100s of roads" is not something that requires powerful routing
algorithms. Check out the Boost Graph Library if you're developing in
C++, or pgrouting which does routing in a PostgreSQL database (and could
easily be configured to route only on bits that conform to some WHERE
uid=1234 query).

You are unlikely to find a software-as-a-service API for that since it
would mean you'd have to transfer the full graph to the search engine
with every request - waste of time and resources.

Bye
Frederik

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

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


Re: [OSM-talk-fr] Comment tagger cette ex-départementale à une voie ?

2019-05-20 Per discussione marc marc
globalement tout a fait d'accord
mais juste pour rappeler le sens des tag d'accès sur les way :
celui de correspondre à des panneaux imposant une restriction légale.
donc y-a-t-il un panneau à l'entrée ?
les restrictions liés aux contraintes physiques de la barrière
se renseignent sur la(les) barrières concernées

Par ailleurs s'il n'y a pas de panneau, rien n'interdit une moto, 
mobylette, dans ce cas motor_vehicle=no n'est pas adapté.

tracktype sur un non-track est souvent un résidu d'un changement de tag 
de highway=* ou une imitation du résultat, je trouve que cela n'a pas de 
sens ni d'intérêt comparé au tag surface qu'on peux raffiner avec smoothness


Le 20.05.19 à 23:46, Gwenaël Jouvin via Talk-fr a écrit :
> access=yes est inutile, les routes de ces catégories sont en accès pour tout 
> le monde par défaut.
> 
> Restreindre les types d’utilisateurs interdits suffit, en l’occurence les 
> motorisés avec motor_vehicle=no.
> On pourrait affiner en vérifiant si les cavaliers sont autorisés ou non.
> 
> Pourquoi pas pour path, ça collerait avec les dimensions.
> Dans ce cas, pas besoin de la restriction d’accès qui est implicite.
> Par contre, ajouter surface=asphalt voire tracktype=1 me parraissent 
> intéressants pour se démarquer de l’usage « classique » de path, le chemin de 
> terre.
> 
> Important aussi, indiquer la largeur maximale admissible par la barrière 
> (maxwidth) et si elle est compatible avec les fauteuils roulants (wheelchair).
> 
> Gwenaël
> 
> 
> Le 20/05/2019 à 23:30, Shohreh a écrit :
>> France mailing list wrote
>>> On peut ajouter motor_vehicle=no, avec éventuellement agricultural=yes si
>>> les engins d’exploitation agricole sont toujours autorisés.
>>
>> Dans mon dos, voici à quoi ressemble la barrière piéton/vélo (-cargo
>> welcome):
>>
>> https://postimg.cc/75KjDkB6
>>
>> On ne dirait pas que les engins agricoles y soient les bienvenus. Première
>> fois que je vois un truc de ce genre :-/
>>
>> Quid de ça ?
>> highway=unclassified
>> access=yes, motor_vehicle=no
>>
>>
>>
>> --
>> 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
> 

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


Re: [OSM-talk-fr] Re: Comment tagger cette ex-départementale à une voie ?

2019-05-20 Per discussione Shohreh
How's about this?

highway=path
tracktype=grade1 
access=yes
motor_vehicle=no



--
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] Re: Comment tagger cette ex-départementale à une voie ?

2019-05-20 Per discussione Gwenaël Jouvin via Talk-fr
Erratum : tracktype=grade1
https://wiki.openstreetmap.org/wiki/Key:tracktype

« It is primarily used in combination with highway=track (around 96% of uses) 
but it is also noticeable usage on highway=service, highway=path, 
highway=unclassified. This tag is useful to provide info about road quality, 
especially for unpaved roads. »



Le 20/05/2019 à 23:46, Gwenaël Jouvin via Talk-fr a écrit :
> access=yes est inutile, les routes de ces catégories sont en accès pour tout 
> le monde par défaut.
> 
> Restreindre les types d’utilisateurs interdits suffit, en l’occurence les 
> motorisés avec motor_vehicle=no.
> On pourrait affiner en vérifiant si les cavaliers sont autorisés ou non.
> 
> Pourquoi pas pour path, ça collerait avec les dimensions.
> Dans ce cas, pas besoin de la restriction d’accès qui est implicite.
> Par contre, ajouter surface=asphalt voire tracktype=1 me parraissent 
> intéressants pour se démarquer de l’usage « classique » de path, le chemin de 
> terre.
> 
> Important aussi, indiquer la largeur maximale admissible par la barrière 
> (maxwidth) et si elle est compatible avec les fauteuils roulants (wheelchair).
> 
> Gwenaël
> 
> 
> Le 20/05/2019 à 23:30, Shohreh a écrit :
>> France mailing list wrote
>>> On peut ajouter motor_vehicle=no, avec éventuellement agricultural=yes si
>>> les engins d’exploitation agricole sont toujours autorisés.
>>
>> Dans mon dos, voici à quoi ressemble la barrière piéton/vélo (-cargo
>> welcome):
>>
>> https://postimg.cc/75KjDkB6
>>
>> On ne dirait pas que les engins agricoles y soient les bienvenus. Première
>> fois que je vois un truc de ce genre :-/
>>
>> Quid de ça ?
>> highway=unclassified
>> access=yes, motor_vehicle=no
>>
>>
>>
>> --
>> 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
> 

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


Re: [Talk-de] boundarys / river als boundary / admin_level?

2019-05-20 Per discussione wambacher
Jetzt mal Butter bei die Fische:

Hast du den Export der Boundaries überhaupt ausprobiert? Ich könnte auch
in den Logfiles nachsehen, aber warte erstmal ab.

"Komische" Poly-Files hab ich bei meiner Software übrigens schon lange
nicht mehr erlebt.( muss ca 6-7 Monate her sein, dass es da mal ein
Ticket zu gab)

Was brauchst du denn genau?
- Mehr als eine Grenze auf einem Schlag? No Problem.
- Täglich die aktuellen Grenzen einer Liste? Null Problem, wenn die
Liste maximal 50 Ids einhält. Wenn mehr, dann halt 2 oder mehr Befehle.
- Alle Grenzen eines Landes mit AL4 (z.B. alle Bundesländer von DEU) -
null Problemo.
- oder auch alle AL3 *und *Al4 von Papua-Neuguinea, jede Grenze ein
separates File? 1 Befehl reicht.
- Die Grenzen von DACH als *ein* Polygon, also ohne innere
Ländergrenzen? - kein Problem.

Alles ohne das GUI verwenden zu müssen. Einfacher Batch mit einen
Exportbefehl reicht (wenn du nicht gerade Win10 verwendest, was ich bei
dir aber für unrealistisch halte).

Und natürlich alles bei Bedarf mit frei definierbaren Buffern ohne
Überlappungen.

Ratlose Grüße

walter

-- 
My projects:

Admin Boundaries of the World 
Missing Boundaries

Emergency Map 
Postal Code Map (Germany only) 
Fools (QA for zipcodes in Germany) 
Postcode Boundaries of Germany 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-at] Allgemeine Hilfestellung

2019-05-20 Per discussione Kevin Kofler
PS:

> Nabble wurde bereits erwähnt. Ein fortgeschrittenerer Gateway ist Gmane,
> der den Zugriff über einen NNTP/Usenet-Newsreader ermöglicht. Dazu benutze
> ich (im Programm KNode) derzeit folgende Einstellungen:
> Server: news.gmane.org
> Port: 119
> Verschlüsselung: TLS (gemeint ist STARTTLS, wo der normale NNTP-Port 119
> verwendet wird und mit dem STARTTLS-Befehl die Verschlüsselung aktiviert
> wird – einen eigenen verschlüsselten Port gibt es auf Gmane seit ein paar
> Monaten nicht mehr, auf dem dafür vorgesehenen Port 563 ist nichts mehr).

Die dieser Mailingliste entsprechende Newsgroup habe ich noch vergessen:
Newsgroup: gmane.comp.gis.openstreetmap.region.at
(Die befindet sich in Newsreadern nämlich nicht in den Servereinstellungen, 
sondern du mußt auf dem Server news.gmane.org eine oder mehrere Newsgroups 
"abonnieren", um auf die entsprechenden Mailinglisten zuzugreifen. Die Mails 
werden dir dadurch aber nicht ge-e-mailt, sondern dein Newsreader holt die 
neuen Mails von Gmane ab, wenn du die "abonnierte" Newsgroup öffnest.)

Mit freundlichen Grüßen,
Kevin Kofler


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


Re: [OSM-talk-fr] Comment tagger cette ex-départementale à une voie ?

2019-05-20 Per discussione Gwenaël Jouvin via Talk-fr
access=yes est inutile, les routes de ces catégories sont en accès pour tout le 
monde par défaut.

Restreindre les types d’utilisateurs interdits suffit, en l’occurence les 
motorisés avec motor_vehicle=no.
On pourrait affiner en vérifiant si les cavaliers sont autorisés ou non.

Pourquoi pas pour path, ça collerait avec les dimensions.
Dans ce cas, pas besoin de la restriction d’accès qui est implicite.
Par contre, ajouter surface=asphalt voire tracktype=1 me parraissent 
intéressants pour se démarquer de l’usage « classique » de path, le chemin de 
terre.

Important aussi, indiquer la largeur maximale admissible par la barrière 
(maxwidth) et si elle est compatible avec les fauteuils roulants (wheelchair).

Gwenaël


Le 20/05/2019 à 23:30, Shohreh a écrit :
> France mailing list wrote
>> On peut ajouter motor_vehicle=no, avec éventuellement agricultural=yes si
>> les engins d’exploitation agricole sont toujours autorisés.
> 
> Dans mon dos, voici à quoi ressemble la barrière piéton/vélo (-cargo
> welcome):
> 
> https://postimg.cc/75KjDkB6
> 
> On ne dirait pas que les engins agricoles y soient les bienvenus. Première
> fois que je vois un truc de ce genre :-/
> 
> Quid de ça ?
> highway=unclassified
> access=yes, motor_vehicle=no
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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


Re: [OSM-talk-fr] Comment tagger cette ex-départementale à une voie ?

2019-05-20 Per discussione Shohreh
Alternativement, on me suggère dans l'oreillette:

highway=path
foot=designated
bicycle=designated

?



--
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-at] Allgemeine Hilfestellung

2019-05-20 Per discussione Kevin Kofler
Hallo Herbert,

ScubbX wrote:
> Ich ergänze die aufschlussreiche Antwort des Vorposters Negreheb, auch
> wenn dieser es schon gut beschrieben hat. Oft ist es hilfreich, die selbe
> Sache unterschiedlich beschrieben zu hören. :-)

Noch einige Punkte, die noch nicht erwähnt wurden:

Es ist auch möglich, die Mailingliste zu abonnieren, ohne Mails zu bekommen 
(was den Vorteil hat, daß die von der abonnierenden E-Mail-Adresse kommenden 
Mails seitens der Mailingliste nicht als Spam gefiltert werden). Dazu 
einfach unter:
https://lists.openstreetmap.org/listinfo/talk-at
den letzten Punkt "Unsubscribe or edit options" nutzen, mit dem Paßwort 
einloggen (im Zweifelsfall "Remind" klicken, um eine Paßworterinnerung per 
Mail zu bekommen – Mailman speichert die Paßwörter leider im Klartext und 
mailt sie auch als ganz normales Klartext-E-Mail herum), und in den Optionen 
"Mail delivery" auf "Disabled" setzen und mit "Submit My Changes" 
bestätigen.

Das ist allerdings nur dann wirklich sinnvoll, wenn man die Mailingliste 
über einen Gateway liest, der auch das Antworten im richtigen Thread 
ermöglicht. (Wenn du einfach ein neues Mail schickst, kann die Antwort nicht 
zugeordnet werden, egal, ob der Betreff übereinstimmt oder nicht.) Nabble 
wurde bereits erwähnt. Ein fortgeschrittenerer Gateway ist Gmane, der den 
Zugriff über einen NNTP/Usenet-Newsreader ermöglicht. Dazu benutze ich (im 
Programm KNode) derzeit folgende Einstellungen:
Server: news.gmane.org
Port: 119
Verschlüsselung: TLS (gemeint ist STARTTLS, wo der normale NNTP-Port 119 
verwendet wird und mit dem STARTTLS-Befehl die Verschlüsselung aktiviert 
wird – einen eigenen verschlüsselten Port gibt es auf Gmane seit ein paar 
Monaten nicht mehr, auf dem dafür vorgesehenen Port 563 ist nichts mehr).

Und, um noch einmal auf die Thematik mit dem Einsortieren der Antworten 
zurückzukommen, weil das ein häufiger Anfängerfehler ist: Umgekehrt antworte 
bitte nicht auf ein bestehendes E-Mail, wenn du eine neue Diskussion starten 
willst, weil sonst das Mail vielerorts in den unpassenden Thread einsortiert 
wird, selbst, wenn du den Betreff komplett umschreibst. (Nicht nur die 
Archive, sowie Gateways wie Nabble und Gmane, sondern auch viele E-Mail-
Clients unterstützen eine Thread-Ansicht, was für Mailinglisten sehr wichtig 
ist, um den Überblick zu bewahren. Und da macht es eben einen Unterschied, 
ob du auf ein bestehendes Mail antwortest oder ein neues schreibst.)

Mit freundlichen Grüßen,
Kevin Kofler


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


Re: [OSM-talk-fr] nommite sur les écoles

2019-05-20 Per discussione Christian Rogel


> Le 20 mai 2019 à 12:11, osm.sanspourr...@spamgourmet.com a écrit :
> 
> Le 20/05/2019 à 00:52, marc marc - marc_marc_...@hotmail.com 
>  a écrit :
>> ton exemple avec un "Le Fret" sorti de nulle part du nom officiel
>> en est un bon exemple
> Je pense que les gens parlent aujourd'hui comme hier de l'école de 
> Saint-Fiacre. Sans primaire ni publique ni Le Fret.
> Le Fret ne sort pas de nulle part : c'est le village le plus proche. Par 
> contre utiliser le village puis le hameau, l'ordre est étonnant.
> Sans doute dans ce cas on peut utiliser alt_name ou loc_name.
> 
> Au fait pour les écoles primaires quand on ne peut distinguer la partie 
> maternelle de la partie élémentaire, vous mettez amenity=kindergarden;school 
> ou vous créez arbitrairement deux points ?
> 
> Ne me répondez pas que vous créez un place=village : 
> https://www.openstreetmap.org/node/4520493454/history 
> ...
> 
> Rassurez-vous pour lui Epicerie - Boucherie c'est aussi un village.
> 
> J'ai aussi trouvé landuse=education mais le plus courant semble de 
> privilégier amenity=school.
> 
> 

Je n’arrive pas à saisir en quoi il y a un problème. Sur l’école, il y a 
inscrit ce que les locaux ont trouvé de plus pertinent. Qui somms-nous pour en 
discuter le contenu, l’ordre des composants ?
Ça ressemble à une mentalité jacobine. ;-)

Il pourrait y avoir un (petit) problème si on se posait la question d’un ajout, 
du, par exemple, à une qualification officielle récente.
En tout cas, tout ce que raconte le ministère  doit être pesé mais, sans lui 
donner la moindre priorité.

L’ordre Le Fret/St-Fiacre est le plus logique : beaucoup de locaux peuvent 
savoir qu’il y a une école dans la section de communede Crozon qu’est Le Fret, 
mais peuvent avoir besoin de savoir qu’il ne faut pas la chercher sur le port 
(très joli, liaison maritime pour pendulaires, l’hôtel où j’ai fait un stage 
merveilleux est toujours là), mais un peu dans les terres.


Christian R.

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


Re: [OSM-talk-fr] Comment tagger cette ex-départementale à une voie ?

2019-05-20 Per discussione Shohreh
France mailing list wrote
> On peut ajouter motor_vehicle=no, avec éventuellement agricultural=yes si
> les engins d’exploitation agricole sont toujours autorisés.

Dans mon dos, voici à quoi ressemble la barrière piéton/vélo (-cargo
welcome):

https://postimg.cc/75KjDkB6

On ne dirait pas que les engins agricoles y soient les bienvenus. Première
fois que je vois un truc de ce genre :-/

Quid de ça ?
highway=unclassified
access=yes, motor_vehicle=no



--
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-GB] Miniature railway or minimum gauge?

2019-05-20 Per discussione jc...@mail.com
On 18/05/2019 18:03, Mark Goodge wrote:

> Other 15" railways in the UK (eg, the Evesham Vale Light Railway) are
> mostly tagged as railway=narrow_gauge.

How do you come to this conclusion? Using the list of 15" railways on Wikipedia,
(including the retagged Rhiw Valley) on OSM in the UK are tagged
13 miniature
12 narrow_guage
2 light_rail
1 unspecified.
Plus Wikipedia defines narrow-gauge as starting at 1 ft 11 1/2 in.

> The OSM wiki is correct to distinguish between miniature railways (ie,
> ridable models) and small gauge "real" railways, as this reflects usage
> among railway engineers and enthusiasts in the non-mapping community.

As I'm not a railway engineer or enthusiast I'm not sure what you mean,
so please can you give specific examples?

Jez C

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


Re: [Talk-at] Allgemeine Hilfestellung

2019-05-20 Per discussione ScubbX
Hallo, Herbert!

Ich ergänze die aufschlussreiche Antwort des Vorposters Negreheb, auch wenn
dieser es schon gut beschrieben hat. Oft ist es hilfreich, die selbe Sache
unterschiedlich beschrieben zu hören. :-)
Eine Mailingliste funktioniert folgendermaßen:

Es gibt eine zentrale eMail-Adresse, an die jeder eine eMail schreiben kann.
Diese eMail wird dann automatisch an alle, die sich in die Mailingliste
eingetragen haben, weitergeleitet. Da jeder an solch eine eMail-Adresse
eMails schreiben kann, kommt es leider häufig vor, dass Spamschleudern die
Mailingliste zumüllen. Daher werden eMails von nicht explizit angemeldeten
Personen (weil ja jeder eine eMail an die zentrale eMail-Adresse der
Mailingliste schreiben kann), zu Moderationszwecken zurückgehalten, bis sie
ein Moderator freigibt.
Das heißt, wenn du dich fix in der Mailingliste anmeldest, sollten deine
Beiträge auch unverzüglich erscheinen.

Da jede eMail an alle Mailinglisten-Abonnementen verteilt wird, kannst du
leider nicht auswählen, welche Beiträge du erhältst und welche nicht. Manche
Mapper haben daher Filterregeln in ihrem eMail-Programm angelegt, die eMails
von Mailinglisten automatisch in Unterordner verschiebt, andere haben
überhaupt eine eigene eMail-Adresse nur für Mailinglisten.
Wenn du dich von einer Mailingliste abmelden willst, sollte in der Fußnote
einer jeder eMail von einer Mailingliste ein Link sein, der auf die
Einstellungsseite der Mailingliste führt.

Wenn der Umgang mit den eMails zu verwirrend ist, gibt es ein externes
Service, welches weltweit eine Vielzahl an Mailinglisten automatisch
abonniert und in eine Forum-Ansicht umwandelt. Auch die talk-at Mailingliste
ist dort unter folgendem Link verfügbar:

http://osm-talk-at.1116557.n5.nabble.com/

Diese Antowort habe ich testweise zum Beispiel direkt auf der Seite
verfasst. :-)

Beste Grüße,
ScubbX



--
Sent from: http://osm-talk-at.1116557.n5.nabble.com/

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


Re: [Talk-se] Upphovsrätt på data och polygoner

2019-05-20 Per discussione Erik Johansson
On Mon, May 20, 2019 at 8:02 PM Janos Steiner  wrote:
> • Jag undrar om det finns någon möjlighet (tagg) i OSM för att  hantera 
> SVAR-polygonerna som en egen helhet (tema), tex som Natura 2000 områden i 
> fastlandet?

Jag har inte koll på vad ett vattenadministrativt område är, men jag
misstänker att ingen sådan tagg finns. Och eftersom jag inte vet vad
meningen med dessa är så är det svårt att hitta på en.


> • En viktig fråga också, om dessa vattenadministrativa polygoner är någon 
> värdefull detalj för openstreetmaps?

Jag såg att vissa av dessa har namn som kan vara intressanta, men jag
kan inte bedöma om formen verkligen motsvarar det de benämner e.g. vet
jag inte om  Mysingen verkligen fyller överallt. Så namnen ja formen
nej.


> - Objekt som pirar, bryggor, ankringsplattformar osv är ett unika objekt, men 
> de visas ofta i OSM som en delsträcka i kustlinjen ("natural=coastline").

Om piren är solid ner till botten så har jag själv alltid kartlagt den
som coastline, men om det är en brygga så ska det vara man_made=pier,
men ja det förekommer att även dessa inkluderas i kustlinjer.


Bra jobb med Shape filerna, det går ju att tanka hem kustlinjer för
hela världen om du vill jämföra dessa med Sveriges kustlinjer.
http://openstreetmapdata.com/data/water-polygons

Jag kan inte tillägga mer just nu, hoppas jag har tid under sommaren.

Hälsningar Erik

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


[OSM-talk-fr] Osm dans son terminal !

2019-05-20 Per discussione Cédric Frayssinet

Impressionnant : https://asciinema.org/a/117813?autoplay=1

Cédric


-- 
Dégooglisé !  - Sociétaire Enercoop
, l'énergie militante

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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


Re: [Talk-de] boundarys / river als boundary / admin_level?

2019-05-20 Per discussione Florian Lohoff
Hi,

On Mon, May 20, 2019 at 09:32:25PM +0200, Jochen Topf wrote:
> > besorgt - Problem ist das entgegen der Doku die durch 
> > das ST_Simplify doch kleiner werden und schneiden können. Muss man
> > also im Buffer entsprechend vorsorgen. Ausserdem entstehende da durchaus
> > mal seltsame Multipolygone. 
> 
> Wenn Du alles innerhalb einer Grenze haben willst, kannste das auch mit
> "osmium extract --polygon" machen und die Grenze direkt aus OSM nehmen.
> Wenn Du dann noch die "smart"-Strategie benutzt, dann ist auch die
> Grenze selbst garantiert drin. Vereinfachte Grenzen machen das Ganze
> etwas schneller, aber nicht viel. Und dann musste Dich nicht mit Buffern
> oder so rumärgern.

Ich habe halt hier für meinen ganzen Auswertungsramsch diverse sub PBFs
von Deutschland die ich derzeit mit osmupdate/osmconvert update
und neu beschneide. Dafür brauche ich halt polys.

osmupdate/osmconvert ist da ein wenig eigenwillig was das ausschneiden
angeht. Daher ist mir dann OWL/Regierungsbezirk Detmold um die Ohren
geflogen. Ich würde ja einfach auch osmium umstellen in der pipeline
aber da fehlt mir das mit dem dem automatisch update eines pbfs d.h.
download der change files. 

Ich will doch einfach nur ein geographisches .pbf auf dem aktuellen
stand halten. Und das "consumerdevice" um das zu machen ist
halt osmupdate mit dem -B poly und schon läuft das für doofe.

Die 50+ Jobs werfe ich dann einfach alle 2 Stunden mir slurm in die
Luft und der scheduled mir die durch mit den dependencies.

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-it] Cassette di servizio delle poste

2019-05-20 Per discussione Nogaro
Benvenuto!

 

Adatto allo scopo esiste già:


man_made=street_cabinet + street_cabinet=postal_service


https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstreet_cabinet

 

Ciao,

Alberto

 

From: Francesco Ansanelli  
Sent: 20 May 2019 21:21
To: talk-it@openstreetmap.org
Subject: [Talk-it] Cassette di servizio delle poste

 

Buonasera lista,

 

è la mia prima mail su talk-it, siate clementi. :)

Scrivo perché ho creato una discussione sul wiki in merito alle cassette di 
servizio delle poste che, a mio avviso, andrebbero mappate come "post_depot":

Se qualcuno è interessato a partecipare ecco il link:

  
https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dpost_depot

 

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


Re: [OSM-talk-fr] Comment tagger cette ex-départementale à une voie ?

2019-05-20 Per discussione Gwenaël Jouvin via Talk-fr
On peut ajouter motor_vehicle=no, avec éventuellement agricultural=yes si les 
engins d’exploitation agricole sont toujours autorisés.
Voir la liste sur la page access :
https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation

Un exemple de cas similaire où il a été carrément mis track, un choix qui me 
paraît discutable : la route est toujours en l’état, bitumée et large.
https://www.openstreetmap.org/way/182210028


Gwenaël


Le 20/05/2019 à 21:43, Shohreh a écrit :
> Bonjour,
> 
> Cette départementale à une voie ("Tertiary Road") est à présent fermée aux
> véhicules motorisés — une barrière se trouve en travers pour ne laisser
> passer que les piétons et les vélos :
> 
> https://postimg.cc/rRtjKshs
> 
> Comment taggeriez-vous ça ?
> 
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath
> 
> 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
> 

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


[OSM-talk-fr] Comment tagger cette ex-départementale à une voie ?

2019-05-20 Per discussione Shohreh
Bonjour,

Cette départementale à une voie ("Tertiary Road") est à présent fermée aux
véhicules motorisés — une barrière se trouve en travers pour ne laisser
passer que les piétons et les vélos :

https://postimg.cc/rRtjKshs

Comment taggeriez-vous ça ?

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath

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: [Talk-de] boundarys / river als boundary / admin_level?

2019-05-20 Per discussione Jochen Topf
On Mon, May 20, 2019 at 08:36:18PM +0200, Florian Lohoff wrote:
> On Fri, May 17, 2019 at 07:22:06PM +0200, wambac...@posteo.de wrote:
> > Moin
> > > Am Ende war es vieles - poly von download.geofabrik.de der an einer
> > > winzigen stelle einen node schneidet einer boundary.
> > > osmupdate/osmconvert mit dem poly schneiden dann da einen teil der
> > > boundary weg.
> > 
> > Die Poly-Files der Geofabrik sind fast alle händisch erstellt worden,
> > daher einfach und relativ schnell. Wenn sich aber eine Grenze verändert
> > haben sollte, kann das (nie wieder angefasste) Poly-File schon mal
> > falsch sein.
> > 
> > Mein Tip: /
> > /- https://wambachers-osm.website/boundaries//
> > 
> > - bpoly mit einem Buffer von 1-2 km wählen und dann sind die
> > *tagesaktuell*. ;)
> 
> Da geht nen buffer? Das habe ich wohl übersehen. Habe mir
> jetzt bei 
> 
> http://polygons.openstreetmap.fr/get_poly.py?id=73347=0.02-0.001000-0.005000
> 
> besorgt - Problem ist das entgegen der Doku die durch 
> das ST_Simplify doch kleiner werden und schneiden können. Muss man
> also im Buffer entsprechend vorsorgen. Ausserdem entstehende da durchaus
> mal seltsame Multipolygone. 

Wenn Du alles innerhalb einer Grenze haben willst, kannste das auch mit
"osmium extract --polygon" machen und die Grenze direkt aus OSM nehmen.
Wenn Du dann noch die "smart"-Strategie benutzt, dann ist auch die
Grenze selbst garantiert drin. Vereinfachte Grenzen machen das Ganze
etwas schneller, aber nicht viel. Und dann musste Dich nicht mit Buffern
oder so rumärgern.

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

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


[Talk-it] Cassette di servizio delle poste

2019-05-20 Per discussione Francesco Ansanelli
Buonasera lista,

è la mia prima mail su talk-it, siate clementi. :)
Scrivo perché ho creato una discussione sul wiki in merito alle cassette di
servizio delle poste che, a mio avviso, andrebbero mappate come
"post_depot":
Se qualcuno è interessato a partecipare ecco il link:

https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dpost_depot

Buon mapping
Saluti,
Francesco
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-de] boundarys / river als boundary / admin_level?

2019-05-20 Per discussione Florian Lohoff
On Fri, May 17, 2019 at 07:22:06PM +0200, wambac...@posteo.de wrote:
> Moin
> > Am Ende war es vieles - poly von download.geofabrik.de der an einer
> > winzigen stelle einen node schneidet einer boundary.
> > osmupdate/osmconvert mit dem poly schneiden dann da einen teil der
> > boundary weg.
> 
> Die Poly-Files der Geofabrik sind fast alle händisch erstellt worden,
> daher einfach und relativ schnell. Wenn sich aber eine Grenze verändert
> haben sollte, kann das (nie wieder angefasste) Poly-File schon mal
> falsch sein.
> 
> Mein Tip: /
> /- https://wambachers-osm.website/boundaries//
> 
> - bpoly mit einem Buffer von 1-2 km wählen und dann sind die
> *tagesaktuell*. ;)

Da geht nen buffer? Das habe ich wohl übersehen. Habe mir
jetzt bei 

http://polygons.openstreetmap.fr/get_poly.py?id=73347=0.02-0.001000-0.005000

besorgt - Problem ist das entgegen der Doku die durch 
das ST_Simplify doch kleiner werden und schneiden können. Muss man
also im Buffer entsprechend vorsorgen. Ausserdem entstehende da durchaus
mal seltsame Multipolygone. 

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


[Talk-at] Allgemeine Hilfestellung

2019-05-20 Per discussione Herbert Allmeier




Hallo liebe OSM Gemeinde.

Ich bin neu hier in dieser Mailing Liste und habe absolut keine Idee wie sie funktioniert! Gibt es eine Art Erklärung, Anweisung oder Handbuch wie man hier beitragen kann? Es sieht doch etwas kompliziert aus.

Vielen Danke im Vorraus für eure Hilfe!

lg Herbert

 

Zusatz: Jetzt habe ich schon 10 Mails von dieser Liste[1] bekommen. Allesamt von Themen für die ich mich im Moment nicht interessieren kann, weil ich mich nicht auskenne.

Wie stelle ich da ab? Kann ich das überhaupt abstellen? Kann ich es auf ein Thema beschränken?

Und wieso dauert es so ewing lange bis meine Mail endlich Mal angezeigt wird?

Ich hoffe, das sich das alles klären wird!

 

Zusatz 2: Meine erste Mail ging mit 15. Mai an den Server. Ist der kaputt oder wird hier einfach nichts angezeigt.

Ich würde gerne beitragen und versuche es deswegen bei Talk-at. Hier hoffe ich, dass man mir hier weiterhelfen kann.

Diese - vergleichsweise - ewig langen Wartezeiten im Zeitalter des Internet finde ich doch sehr befremdlich wenn es sich doch um eine Community Diskussionsplattform handeln soll, bei der jeder ohne spezielle Vorkenntnisse beitragen soll (oder irre ich mich hier?)

 

Wenn dies ein Webmaster liest, lass es mich wenigstens wissen, dass du meine Mails löscht. Dann kann ich mir wenigstens die Mühe sparen.

 

Danke für eure Hilfe, Herbert.

 

[1] talk-de





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


[OSM-talk-fr] [MISC][FTTH] Quelques photos.

2019-05-20 Per discussione Jacques Lavignotte

Hi,

Ca s'active autour de chez moi. La fibre se pose en aérien : la petite 
potence en tête de poteau.


Les étiquettes d'identification (il y en a une qui est moche) et les 
beaux poteaux en plastique.



https://postimg.cc/gallery/1htnehc04/

Et c'est quoi les deux cigares au niveau de câble cuivre ?

J.

Je dis *autour* de chez moi : ça dessert les quatre maisons isolées à 
400m mais *pas* chez moi :(


--
GnuPg : C8F5B1E3 Because privacy matters.


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


Re: [OSM-talk-fr] hebdoOSM Nº 460 2019-04-30-2019-05-06

2019-05-20 Per discussione Rpnpif
Le 20 mai 2019, theweekly@gmail.com a écrit :

> Bonjour,
> 
> Le résumé hebdomadaire n° 460 de l'actualité OpenStreetMap vient de paraître 
> *en français*. Un condensé à retrouver sur :
> 
> http://www.weeklyosm.eu/fr/archives/12067/


Voici le vrai 460 : http://weeklyosm.eu/fr/archives/12108

-- 
Alain Rpnpif

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


Re: [OSM-talk-fr] hebdoOSM Nº 460 2019-04-30-2019-05-06

2019-05-20 Per discussione Rpnpif
Le 20 mai 2019, theweekly@gmail.com a écrit :

> Bonjour,
> 
> Le résumé hebdomadaire n° 460 de l'actualité OpenStreetMap vient de paraître 
> *en français*. Un condensé à retrouver sur :
> 
> http://www.weeklyosm.eu/fr/archives/12067/

Encore raté ! C'est toujours le n°459.

-- 
Alain Rpnpif

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


Re: [OSM-talk-fr] nommite sur les écoles

2019-05-20 Per discussione Christian Rogel
Le 19 mai 2019 à 23:05, osm.sanspourr...@spamgourmet.com a écrit :
> 
> Le 18/05/2019 à 23:10, Christian Rogel - christian.ro...@club-internet.fr 
>  a écrit :
>> Peut-être, mais, tu as oublié qu’il n’y a pas que le mapping en fauteuil et 
>> le codage follement abréviateur dans la vie d’OSM.
>> Il manque donc un paragraphe qui dirait normalement, il y a ou aura une 
>> vérification sur le terrain.
>> S’il est inscrit : école publique de Plancoët, on saisit école publique.
>> 
>> Et voilà pourquoi votre geek est muet (d’après Molière ;-) ).
>> Christian R.
> Pas forcément, sur l'école primaire publique de Saint-Fiacre (dénomination 
> officielle) sont écrits "FILLES" et "GARÇONS", ce sont des inscriptions 
> héritées de l'histoire et non un nom. Sur le site de la ville est écrit 
> "Ecole Le Fret-Saint-Fiacre". Sur l'école est affichée ''école primaire 
> publique Le Fret - Saint-Fiacre".
> 
> Pour moi ça reste un mélange nom et description. Et c'est pourquoi je pose la 
> question sur la liste : doit-on suivre bêtement ce qui est écrit (et non 
> inscrit) ?
Pour moi, la restriction pour les « name » génériques (il ne s’agit pas de « 
description » ou alors le sens de ce mot a changé) ne concerne que le mapping 
en fauteuil, car, il peut même y avoir des appellations concurrentes 
(mairie/hôtel de ville/centre civique).

Sur le terrain (« le terrain, vous dis-je », encore du Molière), on reproduit 
ce que l’autorité ou l’ayant-droit a choisi de mettre et on ne va pas attribuer 
le gros lot à celui qui a mis une appellation non générique.

Evidemment, on ne met pas dans « name » la vieille appellation, car, pour ça, 
il y a « old_name ».

Chez moi, il y a une installation de captage des eaux à la porte de laquelle 
est écrit « usine de production d’eau potable de Ker...». Je suppose que des 
unités similaires portent d’autres appellations. Elles sont toutes égales en 
valeur. Keep it simple.


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


[Talk-ko] Problems to correct administrative boundary 'Dong' and 'Li' (동과 리의 행정경계를 수정하는 문제)

2019-05-20 Per discussione Jaeu Jeong
[English]

Hi

You know that South Korea has unique administrative unit 'Dong' and 'Li'.

There are two type of Dong and Li. One is administrative Dong and Li (행정동,
행정리) and other is legal-state Dong and Li. (법정동, 법정리)

Administrative Dong and Li are used as administrative service area of Local
Autonomous Entity.

And Legal-status Dong is used for address system and trading land.

Boundary of these two type of Dong and Li is differ each other.

Problem is that these two of type is SAME ADMINISTRATIVE LEVEL.

So boundary of Dong and Li is conflicted.


I questioned about this problem to OpenStreetMap forum(link
) and get a
solutions.

Don't use boundary=administrative for both: reserve that for the actual
> administrative entity. For the other one use a different boundary=* tag.
> (SK53 wrote)
>

I think it's more proper and reasonable than previous discussion.

< Previous Discussion (Korean) >
(https://forum.openstreetmap.org/viewtopic.php?id=64911)
(https://forum.openstreetmap.org/viewtopic.php?id=64892)

I want to use boundary=administrative tag only for administrative Dong and
Li . Because It's units for actual administrative purpose.

And I want to make new boundary tag for legal-state Dong and Li. They only
used for legal works, So How about using boundary=legal tag?

If this solution is fine to other contributors, I'll modify administrative
boundary.

Best regards

GPIOIPG


[Korean]

안녕하세요,

아시다시피 동과 리는 한국의 독특한 행정구역입니다.

동과 리에는 두 가지 종류가 있습니다.

하나는 행정동과 행정리, 그리고 다른 하나는 법정동과 법정리입니다.

행정동과 행정리는 지자체의 행정적인 서비스 영역으로 사용됩니다.

그리고 법정동과 법정리는 주소체계 및 토지거래 용도로 사용됩니다.

이 두 종류의 동과 리는 서로 경계가 일치하지 않습니다.

문제는 *이 두 종류(법정-/행정-)가 동일한 행정구역 계층이라는 점*입니다.

그래서 *동과 리의 경계 데이터에 충돌*이 발생합니다.


그래서 OSM 포럼에 질문을 올렸고, 해결 방안을 받았습니다.

두 종류에 boundary=administrative 태그를 사용하면 안됩니다: boundary=administrative는 실제 행정
> 구역 용도로 제한합니다. 다른 하나에 대해서는 다른 boundary=* 태그를 사용합니다. (SK53 작성)


제 생각에는 이 방안이 이전에 논의되었던 것보다 적절하고 합리적이라고 생각합니다.

< 기존 논의 >
(https://forum.openstreetmap.org/viewtopic.php?id=64911)
(https://forum.openstreetmap.org/viewtopic.php?id=64892)

행정동과 행정리는 실제 행정 목적으로 만든 구역이므로, boundary=administrative를 사용하고,

법정동과 법정리는 법적인 용도로만 사용되므로, 별도의 boundary 태그를 만들어서 사용하고 싶습니다. boundary=legal
태그와 같은 건 어떨까요?

만약 다른 분들께서도 이 방안이 괜찮다고 생각하시면, 행정 경계를 수정하려고 합니다.

Best regards

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


[OSRM-talk] Interested in consulting for unique routing use case

2019-05-20 Per discussione Zannah Pierce
Hello,

Our team is working on an application that will do routing over
user-provided content (as in, not Open Street Map data). The content to be
used for routing must differ for each user, and is relatively small in
volume (100s of roads, not thousands).

We have found various APIs that route over existing data (e.g. Graphhopper
routing API uses OSM data), but have not identified an offering that covers
the use case above.

We did find software, such as OSRM, that can route over data that we
provide, but it does not handle data that is dynamic per user.

We are looking to find GIS/routing experts who can help solve the problem
of routing over custom, dynamic data.


-- 

Zannah Pierce

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


Re: [Talk-it] Aree naturali protette con relation

2019-05-20 Per discussione Andrea Albani
Il giorno lun 20 mag 2019 alle ore 14:43 Dario Crespi <
dario.cre...@gmail.com> ha scritto:

> Rieccomi.
>
> I boundary di quel tipo senza una relazione non ti interessano?
>
>
> Sì, direi che potrebbero essere utili. Ho adattato il template in modo che
> possa accogliere gli ID delle way.
>
> Dario
>
>
Ottimo. Grazie!

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


Re: [OSM-talk-be] Relations: wanneer? waarom?

2019-05-20 Per discussione Pieter Vander Vennet
Hallo,

Zonder naar de data te kijken: iD maakt idd makkelijk een multipolygon van
een area als één van de zijkanten geknipt wordt bv om een pad door een
oppervlakte te leggen (denk bv aan building_passages, waar de weg door het
gebouw geknipt wordt en het gebouw vaak ook).

Joinen kan vaak door beide ways te selecteren en op de 'C' toets te duwen.
Soms smijt ik alle tags van één van de wegen om dan te joinen, gaat lekker
snel.

En als je eens een hopeloos complex voorbeeldje van véél multipolygonen
wilt zien: de verschillende oppervlakten in
https://www.openstreetmap.org/relation/9118029#map=18/51.15554/3.26831

Met vriendelijke groeten,
Pieter Vander Vennet


Op ma 20 mei 2019 om 11:46 schreef joost schouppe :

> Ik ben in Portugal eens een dorp tegengekomen waar alle gebouwen volgens
> die logica gemapped waren. Vond ik toch wel heel lastig te bewerken.
>
> Veel van dit soort situaties worden veroorzaakt door ID (de web-editor).
> Als je daar een bestaand vlak "verknipt", wordt er automatisch een relatie
> van gemaakt, ook als dat aan het einde van je bewerking niet meer nodig zou
> blijken.
>
> Als algemene regels zou ik zeggen:
> - als je duidelijk ziet dat de situatie "per ongeluk" complex is geworden,
> dan kan je het gerust terugdraaien
> - als je ziet dat een "complexe" stijl eens uitzonderlijk in een verder
> "simpel" en eerder leeg gebied gebruikt wordt, dan kan je vereenvoudigen.
> Anders loop je het risico dat nieuwe mappers het zien, denken dat het zo
> hoort en het verder overnemen
> - als je ziet dat het in dat gebied toch wel af en toe gebruikt wordt, dan
> kan je beter eens met de mapper contact opnemen en je bedenkingen delen.
> Eventueel kan je ook contact opnemen met de lokale community (vaak kan je
> die via https://community.osm.be/ vinden). Bepaalde stijlen van hoe
> precies iets in kaart brengen op grote schaal zonder discussie toepassen,
> wordt nogal gemakkelijk als vandalisme beschouwd. En zelfs als er een
> akkoord over zou zijn, ben je toch nog altijd verondersteld voorzichtig en
> stap voor stap te werk te gaan. Met andere woorden: je bent alvast goed
> bezig met op voorhand deze vraag te stellen.
>
> Op za 4 mei 2019 om 19:29 schreef Wouter Hamelinck <
> wouter.hameli...@gmail.com>:
>
>> De ene weg is ook deel van relatie 3502263 en de andere niet. De
>> bedoeling is hier volgens mij om een stukje grens als gemeenschappelijk te
>> forceren. Niet hoe ik het zou doen (ik zou gewoon twee aparte polygonen
>> tekenen met gemeenschappelijke nodes), maar ik kan de logica volgen.
>>
>> Wouter
>>
>> On Sat, 4 May 2019, 19:10 Karel Adams,  wrote:
>>
>>> Een typisch voorbeeld, dat me ergert omdat ik het niet begrijp:
>>>
>>> Relation 3904284 is opgebouwd uit ways 293877809 en 293877845. Ik zie
>>> tussen de beide ways geen verschil. Is er enige reden om dit zo te
>>> behouden? Ik zou al de extra tags van de relatie overbrengen naar een
>>> van de ways, en dan de andere way ermee "joinen". Simpeler voor de
>>> mappers én voor de database.
>>>
>>> Meer algemeen: regelmatig kom ik zulke toestanden tegen, waar er zonder
>>> enige (voor mij zichtbare) reden met relations geknutseld wordt. Zie ik
>>> het nu te simpel of zien sommige andere mappers het te ingewikkeld?
>>>
>>> Dank,
>>>
>>> Karel
>>>
>>>
>>> ___
>>> 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
>>
>
>
> --
> Joost Schouppe
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 
> ___
> 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] Aree naturali protette con relation

2019-05-20 Per discussione Dario Crespi
Rieccomi.

I boundary di quel tipo senza una relazione non ti interessano?


Sì, direi che potrebbero essere utili. Ho adattato il template in modo che
possa accogliere gli ID delle way.

Dario

Il giorno lun 20 mag 2019 alle ore 13:54 Dario Crespi <
dario.cre...@gmail.com> ha scritto:

> Grazie mille a tutti!
>
> I boundary di quel tipo senza una relazione non ti interessano?
>>
>
> L'uso che devo farne è legato a Wikidata, dove possono essere linkate solo
> le relazioni. Questa informazione andrà a far parte delle liste di aree
> protette fotografabili per WLE, in modo che il fotografo sappia (nei limiti
> del possibile) dove inizia e dove finisce l'area protetta in questione.
> Questo è l'esempio della Lombardia: tutte le aree hanno le coordinate
> geografiche, e quelle che su Wikidata hanno la proprietà OpenStreetMap ID
> con un valore restituiscono anche il link OSM alla relazione (come nel caso
> del Parco nazionale dello Stelvio).
> https://it.wikipedia.org/wiki/Progetto:Wiki_Loves_Earth_2019/Aree/Lombardia
>
>
> Quindi con questo sistema i boundary senza una relazione non sono
> utilizzabili, anche se si potrebbe eventualmente modificare il template che
> genera le liste aggiungendo un parametro che, se valorizzato con l'ID della
> way su OSM, restituisca comunque un link all'area protetta su OSM. Ci
> penso...
>
> Dario
>
> Il giorno dom 19 mag 2019 alle ore 20:07 Martin Koppenhoefer <
> dieterdre...@gmail.com> ha scritto:
>
>> se ti interessano le aree protette in generale dovresti vedere anche il
>> tag leisure=nature_reserve
>>
>> Ciao, Martin
>> ___
>> 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] Aree naturali protette con relation

2019-05-20 Per discussione Andrea Albani
Il giorno lun 20 mag 2019 alle ore 13:55 Dario Crespi <
dario.cre...@gmail.com> ha scritto:

> Grazie mille a tutti!
>
> I boundary di quel tipo senza una relazione non ti interessano?
>>
>
> L'uso che devo farne è legato a Wikidata, dove possono essere linkate solo
> le relazioni. Questa informazione andrà a far parte delle liste di aree
> protette fotografabili per WLE, in modo che il fotografo sappia (nei limiti
> del possibile) dove inizia e dove finisce l'area protetta in questione.
> Questo è l'esempio della Lombardia: tutte le aree hanno le coordinate
> geografiche, e quelle che su Wikidata hanno la proprietà OpenStreetMap ID
> con un valore restituiscono anche il link OSM alla relazione (come nel caso
> del Parco nazionale dello Stelvio).
> https://it.wikipedia.org/wiki/Progetto:Wiki_Loves_Earth_2019/Aree/Lombardia
>
>
> Quindi con questo sistema i boundary senza una relazione non sono
> utilizzabili, anche se si potrebbe eventualmente modificare il template che
> genera le liste aggiungendo un parametro che, se valorizzato con l'ID della
> way su OSM, restituisca comunque un link all'area protetta su OSM. Ci
> penso...
>

Avevo cominciato a vedere delle aree naturali in provincia di Pavia
diventare delle relazioni mono-member... e ora immagino di averne capito il
motivo :-)

L'iniziativa è ovviamente lodevole e supportabile,  ma direi che un
corollario del classico "non mappare per il rendering" dovrebbe essere "non
mappare per Wikipedia".

La modifica del template a cui stai pensando è sicuramente la strada più
adatta per essere conforme a quanto è OSM... e i mapper ringrazieranno.

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


Re: [Talk-it] Aree naturali protette con relation

2019-05-20 Per discussione Dario Crespi
Grazie mille a tutti!

I boundary di quel tipo senza una relazione non ti interessano?
>

L'uso che devo farne è legato a Wikidata, dove possono essere linkate solo
le relazioni. Questa informazione andrà a far parte delle liste di aree
protette fotografabili per WLE, in modo che il fotografo sappia (nei limiti
del possibile) dove inizia e dove finisce l'area protetta in questione.
Questo è l'esempio della Lombardia: tutte le aree hanno le coordinate
geografiche, e quelle che su Wikidata hanno la proprietà OpenStreetMap ID
con un valore restituiscono anche il link OSM alla relazione (come nel caso
del Parco nazionale dello Stelvio).
https://it.wikipedia.org/wiki/Progetto:Wiki_Loves_Earth_2019/Aree/Lombardia

Quindi con questo sistema i boundary senza una relazione non sono
utilizzabili, anche se si potrebbe eventualmente modificare il template che
genera le liste aggiungendo un parametro che, se valorizzato con l'ID della
way su OSM, restituisca comunque un link all'area protetta su OSM. Ci
penso...

Dario

Il giorno dom 19 mag 2019 alle ore 20:07 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> se ti interessano le aree protette in generale dovresti vedere anche il
> tag leisure=nature_reserve
>
> Ciao, Martin
> ___
> 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-ca] hebdoOSM Nº 460 2019-04-30-2019-05-06

2019-05-20 Per discussione theweekly . osm
Bonjour,

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

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

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

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


[OSM-talk-fr] hebdoOSM Nº 460 2019-04-30-2019-05-06

2019-05-20 Per discussione theweekly . osm
Bonjour,

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

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

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

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


[Talk-ht] hebdoOSM Nº 460 2019-04-30-2019-05-06

2019-05-20 Per discussione theweekly . osm
Bonjour,

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

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

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.


Re: [Talk-it] Source dubbio

2019-05-20 Per discussione Martin Koppenhoefer
Am Do., 16. Mai 2019 um 18:17 Uhr schrieb Andrea Enzo <
andrea.lattm...@ga-2.it>:

> Da quello che so un membro della DWG è iscritto alla nostra ml.




niente, le modifiche problematiche ci sono ancora. Non credo la DWG stia
sistematicamente monitorando le nostre discussioni, soltanto quando
qualcuno segnala un problema vengono eventualmente qui a commentare.

Li scrivo io adesso.

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


Re: [OSM-talk-fr] nommite sur les écoles

2019-05-20 Per discussione osm . sanspourriel

Le 20/05/2019 à 00:52, marc marc - marc_marc_...@hotmail.com a écrit :


ton exemple avec un "Le Fret" sorti de nulle part du nom officiel
en est un bon exemple


Je pense que les gens parlent aujourd'hui comme hier de l'école de
Saint-Fiacre. Sans primaire ni publique ni Le Fret.

Le Fret ne sort pas de nulle part : c'est le village le plus proche. Par
contre utiliser le village puis le hameau, l'ordre est étonnant.

Sans doute dans ce cas on peut utiliser alt_name ou loc_name.

Au fait pour les écoles primaires quand on ne peut distinguer la partie
maternelle de la partie élémentaire, vous mettez
amenity=kindergarden;school ou vous créez arbitrairement deux points ?

Ne me répondez pas que vous créez un place=village :
https://www.openstreetmap.org/node/4520493454/history...

Rassurez-vous pour lui Epicerie - Boucherie c'est aussi un village.

J'ai aussi trouvé landuse=education mais le plus courant semble de
privilégier amenity=school.

Jean-Yvon

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


Re: [OSM-talk-be] Relations: wanneer? waarom?

2019-05-20 Per discussione joost schouppe
Ik ben in Portugal eens een dorp tegengekomen waar alle gebouwen volgens
die logica gemapped waren. Vond ik toch wel heel lastig te bewerken.

Veel van dit soort situaties worden veroorzaakt door ID (de web-editor).
Als je daar een bestaand vlak "verknipt", wordt er automatisch een relatie
van gemaakt, ook als dat aan het einde van je bewerking niet meer nodig zou
blijken.

Als algemene regels zou ik zeggen:
- als je duidelijk ziet dat de situatie "per ongeluk" complex is geworden,
dan kan je het gerust terugdraaien
- als je ziet dat een "complexe" stijl eens uitzonderlijk in een verder
"simpel" en eerder leeg gebied gebruikt wordt, dan kan je vereenvoudigen.
Anders loop je het risico dat nieuwe mappers het zien, denken dat het zo
hoort en het verder overnemen
- als je ziet dat het in dat gebied toch wel af en toe gebruikt wordt, dan
kan je beter eens met de mapper contact opnemen en je bedenkingen delen.
Eventueel kan je ook contact opnemen met de lokale community (vaak kan je
die via https://community.osm.be/ vinden). Bepaalde stijlen van hoe precies
iets in kaart brengen op grote schaal zonder discussie toepassen, wordt
nogal gemakkelijk als vandalisme beschouwd. En zelfs als er een akkoord
over zou zijn, ben je toch nog altijd verondersteld voorzichtig en stap
voor stap te werk te gaan. Met andere woorden: je bent alvast goed bezig
met op voorhand deze vraag te stellen.

Op za 4 mei 2019 om 19:29 schreef Wouter Hamelinck <
wouter.hameli...@gmail.com>:

> De ene weg is ook deel van relatie 3502263 en de andere niet. De bedoeling
> is hier volgens mij om een stukje grens als gemeenschappelijk te forceren.
> Niet hoe ik het zou doen (ik zou gewoon twee aparte polygonen tekenen met
> gemeenschappelijke nodes), maar ik kan de logica volgen.
>
> Wouter
>
> On Sat, 4 May 2019, 19:10 Karel Adams,  wrote:
>
>> Een typisch voorbeeld, dat me ergert omdat ik het niet begrijp:
>>
>> Relation 3904284 is opgebouwd uit ways 293877809 en 293877845. Ik zie
>> tussen de beide ways geen verschil. Is er enige reden om dit zo te
>> behouden? Ik zou al de extra tags van de relatie overbrengen naar een
>> van de ways, en dan de andere way ermee "joinen". Simpeler voor de
>> mappers én voor de database.
>>
>> Meer algemeen: regelmatig kom ik zulke toestanden tegen, waar er zonder
>> enige (voor mij zichtbare) reden met relations geknutseld wordt. Zie ik
>> het nu te simpel of zien sommige andere mappers het te ingewikkeld?
>>
>> Dank,
>>
>> Karel
>>
>>
>> ___
>> 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
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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


[OSM-talk-be] join us at State of the Map

2019-05-20 Per discussione joost schouppe
Hi,

Every year, the global OpenStreetMap convenes for a long weekend of
presentations and workshops about the state of the map. More than just a
chance to learn new things, it is a place where you get to meet all those
people you only know by their username or e-mail.

Last year, for State of the Map Milan, a small group of us Belgians rented
an AirBnB together. It was fun and cost-effective.
This year, it's even closer to home, in Heidelberg, Germany.

Please send me a message if you would like to join this years' group!
The sooner we know how many people will join us, the easier it will be to
find a nice place. I aim for mid June to start organizing, so let me know
by then.

For more details about the event, check out https://2019.stateofthemap.org/

-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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


Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

2019-05-20 Per discussione Grigory Rechistov via Talk-se

Hej,
Jag är nu klar med Katrineholms kommuns rutor. Det blev 10 nya rutor av 45 som
täcker kommunens begränsningsbox eftersom kommunen redan var väl kartlagd.
Jag tror att den fick data av bättre kvalité än mitt första försök med Vingåkers
kommun. Jag håller dessutom på att rätta till några platser med överdrivet 
förenklade
sträckor i Vingåkers område. Jag tror att jag behöver dokumentera det i ett 
slags
"mellanresultats rapport" innan jag glömmer några små detaljer.
Med erfarenhet över dessa två delareor förbättrade jag mina skript för att 
försöka
hitta bättre balans mellan datats volym, risk för konflikter och andra aspekter.
Jag sammanfattade detta i en bearbetningsguide [2] där jag beskriver hur man 
väljer vilka rutor ska , hur man löser vanliga typer konflikter mellan gamla 
och 
nya sträckor, hur man laddar upp datat med mera.
Jag har genererat rutor för följande delareor: 0117-Östersunds, 0136-Kiruna, 
0272-Åre.
Länkar till OSM-filer samt samordningstabeller är tillgängliga i tabellen på 
wikisidan [1].
Hittills hag jag hunnit kika på ett fåtal rutor i Åres kommun och kan bedöma 
att 
följande saker kommer att vara annorlunda med dem.
1. Eftersom delarean 0272 är betydligt större än förra områden innehåller den 
drygt 10 gånger mer rutor.
2. Samtidigt är delarean såpass värre kartlagd att jag förväntar mig se få 
konflikter
för de flesta rutor. Det är helt enkelt inte så många befintliga objekt att 
överlappa med. Så jag hoppas att det blir mindre manuellt arbete per ruta i 
snitt.
3. En del befintliga sträckor i området är ganska ungefärliga, t ex sjöar är
ofta grovt ritade. Flertal mindre tjärnar saknas helt. Importdatat har även
avsevärt bättre kanter på vattenobjekt, men denna import inkluderar 
inte några vattenytor.
4. Eftersom Åres kommun ligger nära Norges gräns kan några nya effekter uppstå
på grund av detta, vet inte ännu vilka.
Jag ämnar nu börja med 0272-Åre. Alla är välkomna att bidra nu eftersom det 
finns
hundratals rutor att granska och eventuellt ladda upp. Om någon vill ha
importrutor för en annan kommun kan jag producera dem på förfrågan. Jag vill
också avråda er använda äldre OSM-filer för hela kommuner som jag tidigare 
producerade (v1 och v2 i wikitabellen) eftersom sträckor i dem är ofta för grovt
förenklade, liknande till Vingåkers ursprungliga data.
1.  
https://wiki.openstreetmap.org/wiki/Import/Catalogue/NMD_2018_Import_Plan/Status_per_subarea
  
2. 
https://wiki.openstreetmap.org/wiki/Catalogue/NMD_2018_Import_Plan/Rutbearbetningsprocess
>Понедельник, 13 мая 2019, 22:32 +03:00 от Grigory Rechistov 
>:
>
>Hej!
>
>Några uppdateringar.
>
>1. `plow-roads.py` skriptet [1] är färdig och kan användas för att ta bort de
>   nya noder som sitter för nära till vägar. Det gör att nya ytor inte får ha
>   några "midjor" över vägar. Jag kommer att använda den för alla kommande 
>rutor.
>
>2. Som förväntat blir sammanfogningsprocessen rejält jobbigt när det redan
>   finns gott om kartlagda data för en ruta. I sådana fall är det enklare att
>   kartlagga de resterande objekt manuellt än att försöka fix alla varningar
>   som uppstår efter tillämpningen på importlagret.
>   Jag uppskattar att det finns 3-4 rutor kvar som enkelt går att lägga till
>   till Katrineholms kommun.
>
>3. JOSM är inte lika pålitlig vid datauppladdningar som man skulle förvänta 
>sig.
>   Det hade hänt några gånger med mig att under en större uppladdning skickades
>   första några tusen objekt iväg, sedan hände ingenting. Efter en timme 
>stängdes
>   ändringsuppsättningen. Man kunde se det i webbläsaren. Trots det visade JOSM
>   inget fel, som om något fel inte hade hänt. Det går egentligen att få egna
>   ändringar fram, men processen blir onödigt nervös. Man behöver radera flera
>   dubbletter på nya objekt efter några avbrutna uppladdningsförsök. Jag vill 
>nu
>   syssla med alternativa sätt att ladda datat upp.
>
>Efter jag är klar med den nuvarande kommunen kommer jag att tillverka nya rutor
>för en annan kommun. Kan någon föreslå en nästa kommun som redan inte är väl
>kartlagd? Så jag hoppas att andra skulle kunna bidra med det.
>
>Jag planerar tillämpa alla förbättringar till datat och processen för att göra
>den så smidigt som möjligt. Jag hoppas att jag fått gott om läxan nu och inte 
>ska
>göra samma misstag.
>
>1. Generera om ett maskeringlager av en ny dataexport. Att använda ett åldrat
>   masklager innebär högre risk för överlappande polygoner.
>2. Klippa ut rutor mer noggrant så att intilliggande rutor inte överlappas. Jag
>   råkade tillämpa projicering och skärning i fel ordning med Katrineholms 
>kommun,
>   någonting som är tråkigt att rätta till på efterhand.
>3. Ploga bort rymden runt motorvägar och tillämpa andra verktyg/skript som jag
>   hittills har skapat.
>4. Ta hänsyn till kommuners gränser för att undvika problem med överlappande
>   rutor efteråt. Min granskning av importdata vid Vingåkers/Katrineholms 
>gränser
>   visade sig att det var en rätt beslut att inte låta 

Re: [talk-au] use of addr:unit

2019-05-20 Per discussione David Wales
Hi Sebastian,

My current approach is to keep the node which refers to the general
address (e.g. addr:housenumber=115),
and to put the other nodes (e.g. 1/115, 2/115, 3/115, 4/115) into a
'FOR-MANUAL-REVIEW' file.

My theory is that if someone is motivated to map them properly, they can
then do the full 3D indoor mapping!

Regards,
David Wales

On 19/5/19 1:41 pm, Sebastian S. wrote:
> Well David my question originated from the address import undertaking.
> As I was dispersing nodes I though why not combine all into one and
> add the information via the unit tag.
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> On 17 May 2019 2:14:00 pm AEST, David Wales 
> wrote:
>
> Hi Sebastian,
>
> If you want to go crazy, you could try Simple Indoor Tagging:
>
> https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging
> https://wiki.openstreetmap.org/wiki/Indoor_Mapping
>
> This allows you to separately map each floor of the building, thus
> allowing each address to be mapped specifically!
>
> Regards,
> David Wales
>
> On 17/5/19 9:53 am, Andrew Harvey wrote:
>> Agreed,  if it's an apartment block, then just the street address
>> should be enough. The unit field would be more helpful for say
>> townhouses where the units are spread out and you could tag
>> individually, or shops as Graeme notes.
>>
>> There is
>> also https://wiki.openstreetmap.org/wiki/Key:building:flats which
>> you can add to t he block of flats/apartments to tag how many
>> units are contained in the building. This is useful for people to
>> determine density (even though most people would just use GNAF
>> etc for this rather than OSM, some new developments OSM could be
>> ahead of GNAF and the other state address databases).
>>
>> On Fri, 17 May 2019 at 08:13, Graeme Fitzpatrick
>> mailto:graemefi...@gmail.com>> wrote:
>>
>>
>>
>> On Thu, 16 May 2019 at 23:51, Andrew Harvey
>> mailto:andrew.harv...@gmail.com>>
>> wrote:
>>
>> To me they are all the same. I think addr:flats given
>> it's documented on the wiki and is in use is the best tag
>> to use. Open to other opinions.
>>
>>
>> I usually just tag the whole building with the street address
>> (100 This Street, Somewhere, QLD, 1234), & then only add
>> individual unit numbers for shops / offices etc (shop=butcher
>> is Unit 1, 100 This Street ...), rather than residential units.
>>
>> Thanks
>>
>> Graeme
>>
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>



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