Re: [Talk-transit] Proposal for simplification of mapping public transport

[Roland Olbricht]

Hi Polyglot,


https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_map_all_stops_as_nodes
I do agree that it would be easier for everyone to have one and only one 
member on the line relation per actual stop.


However, trains and sometimes also trams can have a significant length. 
Walking the full length of a train can take as long as 7 or 8 minutes. 
There are applications that send people before stepping on the train to 
the right section to have a shortest possible walk after getting off 
(search for e.g. "london tube exit routing", no link here to not 
advertise a specific one).


We render OSM useless for such applications if we force people towards 
adding fictitious nodes for trains. Please note that an easy approach 
like adding a node at the front position of the train does not bail out 
us because there are platforms that are called at in both directions of 
travel. In such cases, also the middle position of a train may vary.


Therefore I suggest to drop the node requirement and keep up the 
requirement to have only one object per stop.


A second thing for simplication: I suggest to require always a "name" 
tag on the member object or multiple "name:XX" tags if there is no 
preferred name in a multilingual setting. This way we could safely 
ignore relations for stop related objects.


When writing both a plugin for JOSM and the display tool
https://overpass-api.de/public_transport.html
it was the most frustrating part to go on a quest to find the 
appplicable name if people had hidden it in some special relation, 
including scores of new possible kinds of error if one has no or 
multiple names from multiple stop_area relations and so on. This was the 
main reason to discontinue the development.


I consider to write a proposal for the "name" requirement. Would it make 
more sense for you to instead include that in your proposal, i.e. add 
the requirement for the member object to have a "name" or multiple 
"name:XX" tags?


Best regards,
Roland


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

[OSM-ja] 5/12 東京！街歩き！マッピングパーティ：第19回 出張編 小江戸と浅草の中継点「志木」

[yasunari yamashita]

山下です。皆さんこんにちわ

毎月、東京で開催している東京！街歩き！マッピングパーティですが、
5月は12日(土)に初の出張編、埼玉県志木市での開催です。

東京！街歩き！マッピングパーティ：第19回 出張編 小江戸と浅草の中継点「志木」
https://openstreetmap.connpass.com/event/85124/

田子山富士と敷島神社付近をマッピングします。
皆さまの参加をお待ちしています！！
-- 
山下康成＠東京都新宿区
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[Talk-GB] OSM AGM and notification

[Rob Nickerson]

Hi all,

Just a reminder that the event items on the wiki (and therefore in
WeeklyOSM) can be updated by anyone:

https://wiki.openstreetmap.org/wiki/Current_events#How_to_update_the_calendar

The AGM details have been shared to members and via our email newsletter:

   - Federation House, 2 Federation Street, Manchester, M4 4AF.
   - Saturday 19th May
   - 12:00 start
   - Followed by a joint event with Open Data Manchester lasting to around
   5pm.

This week we aim to finalise the post-AGM details. Work In Progress is here:

https://docs.google.com/document/d/15Ceqe8Jet65aEKxWLoYBE3IqTsdoAsUsCRoTkfH9BzA/edit#

The blocker at the moment is probably me. I am the contact with Open Data
Manchester but have been snowed under with work (overtime this weekend :-(
) so haven't had the time to finalise details with them.

As always, OSM UK tasks need not be limited to "Directors". There is
nothing special about us ;-) Help updating the event table on the wiki
would be much appreciated. Likewise any other help that you can provide
would be much appreciated.

Thank you,

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

Re: [Talk-de] natural in natural / natural in landuse / multipolygon?

[goegeo]

Hallo zusammen,

ich habe da noch einen weiteren Fall. Was ist mit natural=water als 
natürlich Vietränke in "landuse=meadow/(farmland)"-Flächen?


(z.B. ways 275835140 / 276053648 / 276036586)

Daneben besteht ein vergleichbares Problem auch bei sogenannten 
"Grüppen" in Marschländereien. Sie werden angelegt bzw. gepflegt, um bei 
hohen Grundwasserständen das auf dem Land befindliche Wasser oberirdisch 
in angrenzende Entwässerungsgräben zu leiten. Solche sind teilweise 
ebenfalls auf Satellitenbildern erkennbar, führen aber nur zeitweise 
Wasser. Die Weide wird vom Landwirt aber auch als Mäh- oder Viehweide 
genutzt.


Freue mich auf Eure Einschätzungen. Gruß goegeo


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

[Talk-es] [Catastro] 29900 Málaga

[dcapillae]

Hola,

Ya está publicado el proyecto de importación de edificios y direcciones del
Catastro en Málaga [1]. La publicación de este proyecto se ha retrasado
respecto a lo inicialmente previsto debido a que la revisión del callejero
nos ha llevado varias semanas. Luego hemos tenido que esperar un par de
semanas adicionales para dar tiempo a que se debatiese la propuesta de
incorporación de datos procedentes del Callejero Digital de Andalucía
Unificado, que inicialmente no estaba prevista en la propuesta de
importación original.

Cualquier usuario interesado está invitado a participar completando alguna
tarea del proyecto. Previamente conviene leerse la guía de importación [2],
y también puede ser útil consultar las respuestas a algunas preguntas
frecuentes [3]. Con la publicación de este proyecto se canalizan los
esfuerzos iniciados hace algún tiempo por un grupo de usuarios que nos
propusimos mapear manualmente todos los edificios de la ciudad [4]. Gracias
a esta propuesta de importación de edificios y direcciones del Catastro
esperamos completar aquellos primeros trabajos iniciales y mejorar todo lo
que se pueda la calidad de los datos existentes.

Respecto a la gestión del proyecto, hemos pensado que sería interesante
hacerla de forma colaborativa, trabajando conjuntamente varios usuarios a la
vez, ya que Málaga es un municipio muy grande, el más grande de la provincia
y con mayor número de edificios. Lo más probable es que tardemos varios
meses en completar los trabajos de importación, así que nos hemos propuesto
trabajar en equipo. Antonio Clavero y yo mismo vamos a gestionar
inicialmente el proyecto, pero estamos abiertos a la posibilidad de que
otros usuarios interesados puedan incorporarse posteriormente si desean
implicarse en los trabajos de validación de tareas.

Quiero aprovechar este mensaje para agradecer la participación de todos los
que habéis contribuido a la importación de edificios en los dos municipios
previamente completados, Totalán y Colmenar. En estos dos proyectos previos
hemos aprendido mucho, y este aprendizaje nos servirá, estoy seguro, para
hacerlo mejor en el presente y en los próximos proyecto que publiquemos en
la provincia de Málaga. Gracias a todos. En particular quiero agradecer la
colaboración de Javier Sánchez, sin cuya desinteresada ayuda nada de esto
habría sido posible.

Para seguir el estado de los proyectos de importación en curso, podéis
consultar la página de resultados [5]. Los progresos de los proyectos
activos en la provincia de Málaga también se pueden seguir desde la página
del wiki dedicada a la provincia. [6]

Termino con una cita del proyecto Building Canada 2020 de la comunidad OSM
canadiense, que espero sirva para hacernos reflexionar sobre el valor de
esta importación y, en general, sobre la importancia de incorporar la
información sobre edificios a los datos del mapa. Del otro lado del
Atlántico, la comunidad OSM canadiense se ha propuesto mapear todos los
edificios de Canadá para el año 2020: 

«Para la economía y la sociedad canadienses, los edificios son un activo de
capital importante, el espacio en el que se concentra gran parte de las
actividades económicas y sociales, un elemento esencial de la seguridad
humana y las infraestructuras físicas que dan forma a nuestra relación con
el entorno natural y contribuyen a la eficiencia y el consumo de energía, y
son hitos de identidad cultural e histórica. Por estas razones, hay una
constelación de dominios de información que se relacionan con edificios, a
nivel municipal, provincial y federal.» [7]

[1] http://tareas.openstreetmap.es/project/56
[2]
https://wiki.openstreetmap.org/wiki/ES:Catastro_español/Importación_de_edificios/Guía_de_importación
[3]
https://wiki.openstreetmap.org/wiki/ES_talk:Catastro_español/Importación_de_edificios/Guía_de_importación#Preguntas_frecuentes
[4] https://www.openstreetmap.org/user/dcapillae/diary/41229
[5]
https://wiki.openstreetmap.org/wiki/ES:Catastro_español/Importación_de_edificios/Resultados
[6] https://wiki.openstreetmap.org/wiki/ES:Provincia_de_Málaga
[7]
https://wiki.openstreetmap.org/w/index.php?title=WikiProject_Canada/Building_Canada_2020=1561194#Known_benefits



-
Daniel Capilla
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

[OSM-talk] Notes sorted by date/user/so on

[Andreas Vilén]

Hi,

I just went through some notes all around the world (or, at least northern
Africa and southern Europe, but even huge cities like central New York have
these) and found lots of easily closable notes. For example two notes
stating that a football stadium does indeed have the name it was tagged
with (one two years old, one two weeks old), 3-4 year anonymous notes
stating "no left turn" (app created not very trustworthy notes), several
reviews of restaurants, two notes about a local supermarket that was tagged
three times and so on. Obviously these are tagged in areas that either lack
active mappers or lack active mappers who look at or even know of the
existence of notes. More than once I have come across notes that have been
resolved since they were created but have not been closed (or in some cases
"fixed, do you want me to fix anything else", unresolved for two years).

Personally I look at all notes that are opened in Sweden, and there are a
lot of them that are closed almost immediately because they are used in the
wrong way. There are a lot of easily closable notes out there that we could
get rid of to get the notes that actually contain usable information easier
to find. In my experience almost bigger town/city contains lots of notes
that are either 1) about something that is already tagged 2) a review or
opinion 3) easily fixable by adding or removing a tag 4) spam.

Therefore I wonder, is it possible to get notes sorted by date in some way?
That would make it easier to find those old notes that have been lying
around forever either waiting for a fix that will never come, have been
fixed long ago or contain outdated or bogus information. It would also be
nice to easily separate anonymous from logged in users. Maybe at least this
is something that someone has thought of creating a QA tool for?

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

Re: [Talk-dk] Andre tags på adressenoder? (WAS: Nyt script til addresseopdateringer)

[Michael Andersen]

> Jeg er en af de "uerfarne", som efterfølgende har fået adskilt adresser og
> andre egenskaber. Eksempel:
> 
> https://www.openstreetmap.org/way/12943/history
> 
> Jeg kan godt forstå princippet om at undgå redundante data, men jeg har ofte
> opdateret adresseinformation for fx butikker på linie med andre
> kontaktinformationer/åbningstider/telefon etc. Det synes jeg giver mening,
> eftersom forskellige programmer (fx mkgmap til Garmins gps'er) benytter
> OSM's kontaktinformationer - herunder adresserne, hvis de findes. Hvis
> adresseinformationer _ikke_ ligger på samme node som butikken, skal man til
> at gætte på den korrekte adresse - oftest den adressenode, som er tættest
> på, men langt fra altid.

Der er her tale om en relateret, men lidt anden situation end den jeg er inde 
på ovenfor.
Det objekt du linker til ovenfor er ikke en importeret adresse og der var 
aldrig nogen osak:* tags på den (men dog en mystisk source=AWS*, som jeg på et 
tidspunkt fjerner fordi den forekommer mig misvisende)

De adresse tags der var på den har du formentlig tilføjet manuelt.

Det der så sker er at Jørn-osm kører en kampagne i forhold til at rydde i op 
vores adresser. Stærkt tiltrængt ganske vist - men han sletter også et stort 
"dobbelte adresser", altså adresseinfo (ofte kun gade & nr) tilføjet POI's ved 
siden af de importerede adresser. Dette var jeg personligt lidt ked af fordi 
det gør det sværere at vurdere om en given forretning er placeret rigtigt på 
kortet.

Da jeg så gør Jørn opmærksom på den tråd Henrik PS startede i oktober (Jørn 
abonnerer tilsyneladende ikke på postlisten) stopper han helt og siden er der 
ikke nogen der har slettet "dobbelte adresser".

> 
> Med andre ord er det en helt traditionel datamodelleringsøvelse - og jeg
> kunne godt tænke mig lidt mere information: Hvornår/hvor er det besluttet,
> at danske adresser skal udskilles fra andre punkter (fx butikker & andre
> POI's?)

Det fortaber sig for mit vedkommende i det dunkle. Jeg opdagede først OSM på 
omkring det tidspunkt hvor de første adresser blev importeret og det varede 
længe før jeg havde tilstrækkelig erfaring til at danne mig en mening om den 
slags

Jeg har endnu ikke nogen helt fast mening om den sag du bringer op her. 
Ligegyldigt hvilken løsning vi vælger er der nemlig nogen "issues" ved det.


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

Re: [Talk-dk] Nyt script til addresseopdateringer

[Michael Andersen]

On søndag den 15. april 2018 19.40.32 CEST Jakob Barfod wrote:
> > > F.eks. bør den kunne finde ud af at flette oplysningerne korrekt
> > > sammen hvis nogen har tilføjet ekstra tags. Hvis adresseknuden senere
> > > forsvinder fra det officielle register, bør den jo nok også lade være
> > > med at slette sådan en knude men i stedet bare slette osak-tagsn'e.
> 
> Helt enig. Det nævnes flere gange i tråden, at DAR kommer til at blive det
> autoritative datagrundlag - og fx slette/ændre adressenoder i OSM, hvis der
> er kommer nye(re) data fra DAR.
> 
> Det synes jeg er en tvivlsom tilgang; der er stor chance for, at OSM's data
> er mere korrekte (fx rettelse af forkerte koordinater) eller fyldestgørende
> (fx i form af supplerende tags) end data fra DAR (jf. mit spørgsmål om
> supplerende tags;
> https://lists.openstreetmap.org/pipermail/talk-dk/2018-April/005026.html).
> 
> Venligst,

Som nævnt tidligere sker det jævnligt at især begyndere ved diverse uheld 
(først og fremmest ved at komme til at "gribe fat" i en node når de forsøger 
at "panne" kortet) kommer til fejlagtigt at rykke adresser op til flere 100 m 
(eksempel fra i dag: https://www.openstreetmap.org/changeset/58115512).

Det sker også jævnligt at folk aktivt forsøger at rette adresser i OSM (flytte 
lidt rundt på dem eller ændre numre). Fint nok. Men som vi flere gange 
tidligere på denne liste har været inde på må det korrekte altså være at 
adresser importeret til OSM fra DAR rettes ved kilden (altså ved henvendelse 
til DAR)




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

Re: [OSM-talk-fr] Import station essence (NavAds)

[Christian Quest]

1500 stations GPL de moins ? ça me semble peu cohérent, il y en avait un
peu plus de 2000 et si les 3/4 avaient disparu, je m'en serai aperçu avec
ma gazinière !

D'après
http://stations.gpl.online.fr/appli/index.php?parEtape=Indicateur=EvolutionNbStations
il y a un peu plus de 1600 stations GPL.


Le 15 avril 2018 à 19:05, Frédéric Rodrigo  a écrit
:

> J'ai codé la suppression de tags lors des propositions de mise à jour.
>
> Voilà ce que ça va proposer de faire :
>  10 
> 101 
> 111 
> 204 
> 750 
>1535 
>
> Bien que le nombre de stations GPL en moins ai l'air énorme, cela me
> semble quand même cohérent.
>
>
> Le 14/04/2018 à 13:27, Jérôme Amagat a écrit :
>
>> Les règles appliqués aux stations service en ce qui concerne cette base
>> de donnée www.prix-carburants.gouv.fr 
>> sont dans les articles 5 et 6 de l'Arrêté du 8 juillet 1988 relatif à la
>> publicité des prix de vente des carburants (modifié en 2006 et 2013) :
>> https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=89E
>> C04583319498E1E1BA44D5C7FCB0C.tplgfr35s_3?cidTexte=JORFTEXT0
>> 0688923=20180414 > r/affichTexte.do;jsessionid=89EC04583319498E1E1BA44D5C7FCB0C
>> .tplgfr35s_3?cidTexte=JORFTEXT00688923=20180414>
>> ça dit que les stations service qui vendent plus de cinq cents mètres
>> cubes par an tous produits confondus doivent alimenter cette base de donnée
>> pour la liste de carburant : gazole, e85, sp95, sp95 e10, gpl (pour le sp98
>> il est indiqué sur le site mais pas dans l'arreté)
>>
>> Pour le problème des carburants qui disparaissent à la vente dans les
>> station mais ne sont pas mis à jour dans osm avec osmose, une solution
>> serait de mettre des valeurs "no" pour les carburants n'étant pas vendu
>> dans la station service.
>> ça a l'avantage de pas avoir à modifier en profondeur le code d'osmose :)
>> juste des petites modifs
>> Ce n'est pas une erreur vu que si les carburants étaient vendus ils
>> seraient indiqué dans la base
>> indiqué clairement qu"il ne sont pas vendu c'est une info pertinente
>> par contre, normalement un tag =no n'est pas indiqué dans osm (ou
>> rarement)
>> osmose va proposer une mise à jour pour toutes les station service déjà
>> intégré :)
>>
>>
>>
>> Le 14 avril 2018 à 10:59, Jérôme Amagat  jerome.ama...@gmail.com>> a écrit :
>>
>>
>>
>> Le 12 avril 2018 à 20:51, Frédéric Rodrigo > > a écrit :
>>
>>
>> Le 12/04/2018 à 19:03, Jérôme Amagat a écrit :
>>
>> En ce qui concerne la base des prix des carburants
>> utilisée sur osmose, j'ai plusieurs remarque :
>>
>> déjà, les info de carburants sont sûrement bonnes mais la
>> géolocalisation (pour au moins les stations restant à
>> intégrer dans osmose) n'est pas toujours bonne voir est
>> très mauvaise.(n'importe où dans la commune ou n'importe
>> où le long de la rue). Donc un import de masse de ces
>> points, ça serait pas terrible... et l’intégration avec
>> osmose est compliqué... il faut chercher avec l'adresse
>> qui est donné sur osmose, regarder les stations déjà
>> existantes (il y a de bonne chance que la station existe
>> déjà mais comme dans la base elle est mal placé osmose ne
>> la met pas dans la catégorie intégration possible)
>>
>> Osmose propose toutes les stations, il ne sait pas qu'elle est
>> mal placé (c'est pour ça qu'il te le demande ;-) )
>>
>>
>> Ces positions très approximative complique la vie à tout le monde,
>> osmose et les contributeur. en plus les adresses renseignées sont
>> parfois pas précise du tout, qu'un nom de rue voir seulement un
>> nom de lieu dit ou de village...
>>
>>
>> Dans les mise a jour proposer par osmose, j'ai
>> l'impression qu'on ne propose que des ajouts ou des
>> modifications de tags et pas des suppressions. Je viens de
>> faire quelques mises à jour avec osmose et on m'a proposé
>> pas mal d'ajout de carburant mais pas de suppression. Je
>> pense que souvent lorsque dans une station on ajoute un
>> carburant c'est en remplacement d'un autre par exemple le
>> sans plomb e10 remplace le sans plomb normal.
>>
>> Tu as raison la suppression de tags n'est pas géré (mais ça
>> pourrait, aide bienvenue).
>>
>> Il y a des stations service qui ont changé de ref dans la
>> la base de donnée source (je sais pas pourquoi) et des
>> stations qui ont cessés d'exister et osmose ne propose pas
>> de supprimer les ref qui ne représente plus des stations
>> en fonctionnement.
>>
>> Osmose, sait le faire, mais ça n'a pas été 

[Talk-it] Mappe mute

[Cascafico Giovanni]

Ciao Listàti,

prima di impelagarmi in qgis, sapete se ci sono in giro servizi per la
generazione di mappe mute (blank maps)?

per esempio, dei fiumi italiani, o campoluoghi ecc.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Lena Essig]

Am 15. April 2018 um 16:42 schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> würdet ihr emergency=ambulance_station auch für Leitstellen (mit
> Krankenwägen) verwenden, die nicht den Rettungsauftrag haben (i.e.
> qualifizierte Krankentransporte machen), oder müssen das Rettungswachen
> sein (funktional, d.h. sie sind aktuell mit Rettungsdienstaufgaben
> beauftragt)?
>

Aktuell gibt es keine Möglichkeit Gebäude als reine Krankentransportwache
zu kennzeichnen, oder? [1]
Diese Möglichkeit wäre natürlich schön um eindeutig zwischen
Krankentransport und Notfallrettung unterscheiden zu können. Hier [2]
werden Möglichkeiten zur Beschreibung von eingesetzten Fahrzeugen gezeigt,
die Nutzung dessen hält sich aber in Grenzen. Ich finde in ganz Deutschland
nur acht Fälle in denen diese Tags verwendet werden [3], obwohl sie
sinnvoll zur Unterscheidung wären. Damit könnten dann auch Leitstellen
welche Fahrzeuge stellen erweitert werden.

@Daniel: Ich denke das Nutzen dieser Tags wäre sinnvoll und sollte
weitergeführt werden.

Grüße
Lena

[1] https://www.openstreetmap.org/node/4352460407#map=16/49.0069/8.5106
[2]
https://wiki.openstreetmap.org/wiki/DE:Tag:emergency=ambulance%20station?uselang=de
[3] https://overpass-turbo.eu/s/xUF 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

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

[osm . sanspourriel]

Vendre moins de 300 m3/an ne veut pas dire ne pas en vendre.

Ce qui explique le cas du GPL.

Je ne vois pas de raison de supprimer ces tags.

Demander avec un streetcomplete si les produits sont en vente me semblerait plus coherent.
 

Jean-Yvon

 
 

Gesendet: Sonntag, 15. April 2018 um 19:05 Uhr
Von: "Frédéric Rodrigo - fred.rodr...@gmail.com" 
An: "Jérôme Amagat" 
Cc: "Discussions sur OSM en français" 
Betreff: Re: [OSM-talk-fr] Import station essence (NavAds)

J'ai codé la suppression de tags lors des propositions de mise à jour.

Voilà ce que ça va proposer de faire :
 10 
    101 
    111 
    204 
    750 
   1535 

Bien que le nombre de stations GPL en moins ai l'air énorme, cela me
semble quand même cohérent.


Le 14/04/2018 à 13:27, Jérôme Amagat a écrit :
> Les règles appliqués aux stations service en ce qui concerne cette
> base de donnée www.prix-carburants.gouv.fr
>  sont dans les articles 5 et 6 de
> l'Arrêté du 8 juillet 1988 relatif à la publicité des prix de vente
> des carburants (modifié en 2006 et 2013) :
> https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=89EC04583319498E1E1BA44D5C7FCB0C.tplgfr35s_3?cidTexte=JORFTEXT00688923=20180414
> 
> ça dit que les stations service qui vendent plus de cinq cents mètres
> cubes par an tous produits confondus doivent alimenter cette base de
> donnée pour la liste de carburant : gazole, e85, sp95, sp95 e10, gpl
> (pour le sp98 il est indiqué sur le site mais pas dans l'arreté)
>
> Pour le problème des carburants qui disparaissent à la vente dans les
> station mais ne sont pas mis à jour dans osm avec osmose, une solution
> serait de mettre des valeurs "no" pour les carburants n'étant pas
> vendu dans la station service.
> ça a l'avantage de pas avoir à modifier en profondeur le code d'osmose
> :) juste des petites modifs
> Ce n'est pas une erreur vu que si les carburants étaient vendus ils
> seraient indiqué dans la base
> indiqué clairement qu"il ne sont pas vendu c'est une info pertinente
> par contre, normalement un tag =no n'est pas indiqué dans osm (ou
> rarement)
> osmose va proposer une mise à jour pour toutes les station service
> déjà intégré :)
>
>
>
> Le 14 avril 2018 à 10:59, Jérôme Amagat  > a écrit :
>
>
>
> Le 12 avril 2018 à 20:51, Frédéric Rodrigo  > a écrit :
>
> Le 12/04/2018 à 19:03, Jérôme Amagat a écrit :
>
> En ce qui concerne la base des prix des carburants
> utilisée sur osmose, j'ai plusieurs remarque :
>
> déjà, les info de carburants sont sûrement bonnes mais la
> géolocalisation (pour au moins les stations restant à
> intégrer dans osmose) n'est pas toujours bonne voir est
> très mauvaise.(n'importe où dans la commune ou n'importe
> où le long de la rue). Donc un import de masse de ces
> points, ça serait pas terrible... et l’intégration avec
> osmose est compliqué... il faut chercher avec l'adresse
> qui est donné sur osmose, regarder les stations déjà
> existantes (il y a de bonne chance que la station existe
> déjà mais comme dans la base elle est mal placé osmose ne
> la met pas dans la catégorie intégration possible)
>
> Osmose propose toutes les stations, il ne sait pas qu'elle est
> mal placé (c'est pour ça qu'il te le demande ;-) )
>
>
> Ces positions très approximative complique la vie à tout le monde,
> osmose et les contributeur. en plus les adresses renseignées sont
> parfois pas précise du tout, qu'un nom de rue voir seulement un
> nom de lieu dit ou de village...
>
>
> Dans les mise a jour proposer par osmose, j'ai
> l'impression qu'on ne propose que des ajouts ou des
> modifications de tags et pas des suppressions. Je viens de
> faire quelques mises à jour avec osmose et on m'a proposé
> pas mal d'ajout de carburant mais pas de suppression. Je
> pense que souvent lorsque dans une station on ajoute un
> carburant c'est en remplacement d'un autre par exemple le
> sans plomb e10 remplace le sans plomb normal.
>
> Tu as raison la suppression de tags n'est pas géré (mais ça
> pourrait, aide bienvenue).
>
> Il y a des stations service qui ont changé de ref dans la
> la base de donnée source (je sais pas pourquoi) et des
> stations qui ont cessés d'exister et osmose ne propose pas
> de supprimer les ref qui ne représente plus des stations
> en fonctionnement.
>
> Osmose, sait le faire, mais ça n'a pas été activé pour les
> stations.
> La ref:FR:prix-carburants vous parait suffisamment stable et
> "importante" pour que ça le soit ?
> Ça signalera les stations sans la ref, ou avec une ref inconnue.
>
>
> Le problème c'est que toutes les stations service ne sont pas dans
> cette base . il me 

[Talk-cz] Fwd: šestý brněnský mapathon na Masarykově univerzitě

[r.stampach]

Zdravím vás, vážení přátelé,

jsem zaměstnancem Geografického ústavu Přírodovědecké fakulty Masarykovy 
univerzity.

Na našem Geografickém ústavu (Kotlářská 2, Brno) se pravidelně uskutečňují 
brněnské Missing Maps mapathony pro organizaci Lékařů bez hranic, kde se 
vytváří data OpenStreetMap pro krizové části světa, které dosud nejsou dobře 
zmapované. Tato data pak používají humanitární organizace pro svou práci. Píši 
sem, protože mapathonů se pravidelně účastní i čtenáři tohoto fóra.

V pořadí osmý mapathon na Masarykově univerzitě se uskuteční ve středu 25. 
dubna 2018 od 17:00 do 21:00. Přesné místo: učebna Z7, Geografický ústav, 
Přírodovědecká fakulta, budova 4, Kotlářská 2, Brno.
Mapa: https://www.openstreetmap.org/way/84965582

Lze si vybrat ze tří skupin. Kromě skupiny začátečníků a skupiny zájemců o 
editaci OpenStreetMap v editoru JOSM, bude i možnost stát se validátorem - 
kontrolorem práce ostatních mapérů. Je to mnohem jednodušší, než to zní. Právě 
validátoři jsou nyní v projektu Missing maps nejvíce potřeba. 

Vítáni jsou ovšem i ti, kteří si chtějí jen přijít zamapovat a nebýt přitom 
rušeni výkladem.

Registraci a více informací najdete na adrese: 
https://www.eventbrite.co.uk/e/brnensky-dubnovy-missing-maps-mapathon-tickets-45174677677

Radim Štampach
Geografický ústav
Přírodovědecká fakulta
Masarykova univerzita

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

Re: [Talk-it] dataset MISE distributori

[Martin Koppenhoefer]

sent from a phone

> On 15. Apr 2018, at 19:59, Andrea Musuruane  wrote:
> 
> Ovviamente il processo di conflation non può fare nulla contro questo tipo di 
> dati errati


infatti, in principio “conflation” deve significare che non si sovrascrivono i 
valori esistenti in osm. Sono tutto per inserire nuovi benzinai dalla lista, e 
anche per aggiungere informazioni dove l’identità del oggetto sembra 
plausibile, ma terrei ciò che abbiamo diverso dal loro dataset, e in quel caso 
potrebbe apparire in una sorta di QA tool (lista di cose da verificare in loco).

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

Re: [Talk-it] dataset MISE distributori

[Andrea Musuruane]

Ciao,

2018-04-13 14:05 GMT+02:00 Cascafico Giovanni :

> Ora dovrebbe essere accessibile il progetto IFS [1] per la revisione degli
> osm changes pre-import. Ho recepito quanto osservato da Andrea Musuruane,
> lasciano solo le informazioni con un minimo di omogeneità.
>

Molto bello il risultato.

Oltre ai distributori chiusi (che sono ancora segnati aperti) o quelli
aperti (ma non ancora in elenco), ho trovato anche il seguente che è
localizzato in modo errato
http://audit.osmz.ru/browse/IFS/25121

Ovviamente il processo di conflation non può fare nulla contro questo tipo
di dati errati; ci deve essere supervisione umana.

Se possibile, bisognerebbe considerare anche i tag con il prefisso
disused:* (tipo disused:amenity=fuel).

Ciao,

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

Re: [Talk-dk] Nyt script til addresseopdateringer

[Jakob Barfod]

> > F.eks. bør den kunne finde ud af at flette oplysningerne korrekt
> > sammen hvis nogen har tilføjet ekstra tags. Hvis adresseknuden senere
> > forsvinder fra det officielle register, bør den jo nok også lade være
> > med at slette sådan en knude men i stedet bare slette osak-tagsn'e.

Helt enig. Det nævnes flere gange i tråden, at DAR kommer til at blive det 
autoritative datagrundlag - og fx slette/ændre adressenoder i OSM, hvis der er 
kommer nye(re) data fra DAR.

Det synes jeg er en tvivlsom tilgang; der er stor chance for, at OSM's data er 
mere korrekte (fx rettelse af forkerte koordinater) eller fyldestgørende (fx i 
form af supplerende tags) end data fra DAR (jf. mit spørgsmål om supplerende 
tags; https://lists.openstreetmap.org/pipermail/talk-dk/2018-April/005026.html).

Venligst,

-- 
Jakob


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

[Talk-dk] Andre tags på adressenoder? (WAS: Nyt script til addresseopdateringer)

[Jakob Barfod]

> Det er meget almindeligt at udlændinge/uerfarne finder en adressenode og
> putter alt muligt andet info på. I mange tilfælde kan det umiddelbart
> virke oplagt at gøre således og ofte virker det ikke som sådan "forkert".
> Dog kan det virke det virke upassende at have alle disse osak:* tags på
> f.eks en butik og hvad sker der f.eks. hvis butikken slettes fordi den er
> lukket eller der er tale om en butik nederst i en etageejendom og den
> derfor ikke er alene om adressen?

[...]

> Steffen Møller/AWSbot "eksporterede" jævnligt diverse "fremmede" tags fra
> osak adressenoder. Eksempler i Århus: https://overpass-turbo.eu/s/xTn
> 
> Jeg har også rutinemæssigt udskilt "fremmede tags" når jeg har observeret
> dem blive påsat og osmviborg er også begyndt at gøre det
> 
> Slettes adresse tags på en node med "fremmede tags" fordi adressen ikke
> eksisterer længere vil jeg anbefale at den tagges med et fixme=*

Jeg er en af de "uerfarne", som efterfølgende har fået adskilt adresser og 
andre egenskaber. Eksempel:

https://www.openstreetmap.org/way/12943/history

Jeg kan godt forstå princippet om at undgå redundante data, men jeg har ofte 
opdateret adresseinformation for fx butikker på linie med andre 
kontaktinformationer/åbningstider/telefon etc.
Det synes jeg giver mening, eftersom forskellige programmer (fx mkgmap til 
Garmins gps'er) benytter OSM's kontaktinformationer - herunder adresserne, hvis 
de findes. Hvis adresseinformationer _ikke_ ligger på samme node som butikken, 
skal man til at gætte på den korrekte adresse - oftest den adressenode, som er 
tættest på, men langt fra altid.

Med andre ord er det en helt traditionel datamodelleringsøvelse - og jeg kunne 
godt tænke mig lidt mere information: Hvornår/hvor er det besluttet, at danske 
adresser skal udskilles fra andre punkter (fx butikker & andre POI's?)

Venligst,

-- 
Jakob


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

Re: [OSM-talk-fr] Import station essence (NavAds)

[Frédéric Rodrigo]

J'ai codé la suppression de tags lors des propositions de mise à jour.

Voilà ce que ça va proposer de faire :
 10 
    101 
    111 
    204 
    750 
   1535 

Bien que le nombre de stations GPL en moins ai l'air énorme, cela me 
semble quand même cohérent.



Le 14/04/2018 à 13:27, Jérôme Amagat a écrit :
Les règles appliqués aux stations service en ce qui concerne cette 
base de donnée www.prix-carburants.gouv.fr 
 sont dans les articles 5 et 6 de 
l'Arrêté du 8 juillet 1988 relatif à la publicité des prix de vente 
des carburants (modifié en 2006 et 2013) : 
https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=89EC04583319498E1E1BA44D5C7FCB0C.tplgfr35s_3?cidTexte=JORFTEXT00688923=20180414 

ça dit que les stations service qui vendent plus de cinq cents mètres 
cubes par an tous produits confondus doivent alimenter cette base de 
donnée pour la liste de carburant : gazole, e85, sp95, sp95 e10, gpl 
(pour le sp98 il est indiqué sur le site mais pas dans l'arreté)


Pour le problème des carburants qui disparaissent à la vente dans les 
station mais ne sont pas mis à jour dans osm avec osmose, une solution 
serait de mettre des valeurs "no" pour les carburants n'étant pas 
vendu dans la station service.
ça a l'avantage de pas avoir à modifier en profondeur le code d'osmose 
:) juste des petites modifs
Ce n'est pas une erreur vu que si les carburants étaient vendus ils 
seraient indiqué dans la base

indiqué clairement qu"il ne sont pas vendu c'est une info pertinente
par contre, normalement un tag =no n'est pas indiqué dans osm (ou 
rarement)
osmose va proposer une mise à jour pour toutes les station service 
déjà intégré :)




Le 14 avril 2018 à 10:59, Jérôme Amagat > a écrit :




Le 12 avril 2018 à 20:51, Frédéric Rodrigo > a écrit :

Le 12/04/2018 à 19:03, Jérôme Amagat a écrit :

En ce qui concerne la base des prix des carburants
utilisée sur osmose, j'ai plusieurs remarque :

déjà, les info de carburants sont sûrement bonnes mais la
géolocalisation (pour au moins les stations restant à
intégrer dans osmose) n'est pas toujours bonne voir est
très mauvaise.(n'importe où dans la commune ou n'importe
où le long de la rue). Donc un import de masse de ces
points, ça serait pas terrible... et l’intégration avec
osmose est compliqué... il faut chercher avec l'adresse
qui est donné sur osmose, regarder les stations déjà
existantes (il y a de bonne chance que la station existe
déjà mais comme dans la base elle est mal placé osmose ne
la met pas dans la catégorie intégration possible)

Osmose propose toutes les stations, il ne sait pas qu'elle est
mal placé (c'est pour ça qu'il te le demande ;-) )


Ces positions très approximative complique la vie à tout le monde,
osmose et les contributeur. en plus les adresses renseignées sont
parfois pas précise du tout, qu'un nom de rue voir seulement un
nom de lieu dit ou de village...


Dans les mise a jour proposer par osmose, j'ai
l'impression qu'on ne propose que des ajouts ou des
modifications de tags et pas des suppressions. Je viens de
faire quelques mises à jour avec osmose et on m'a proposé
pas mal d'ajout de carburant mais pas de suppression. Je
pense que souvent lorsque dans une station on ajoute un
carburant c'est en remplacement d'un autre par exemple le
sans plomb e10 remplace le sans plomb normal.

Tu as raison la suppression de tags n'est pas géré (mais ça
pourrait, aide bienvenue).

Il y a des stations service qui ont changé de ref dans la
la base de donnée source (je sais pas pourquoi) et des
stations qui ont cessés d'exister et osmose ne propose pas
de supprimer les ref qui ne représente plus des stations
en fonctionnement.

Osmose, sait le faire, mais ça n'a pas été activé pour les
stations.
La ref:FR:prix-carburants vous parait suffisamment stable et
"importante" pour que ça le soit ?
Ça signalera les stations sans la ref, ou avec une ref inconnue.


Le problème c'est que toutes les stations service ne sont pas dans
cette base . il me semble qu'il y a une obligation d'y être à
partir d'un certain volume de vente. Donc les petites stations
n'ont pas de ref dans la base source.


Autre chose sur le fonctionnement d'osmose, la source qui
est ajouté aujourd'hui a une date qui est le 30/08/2017

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

[Ryszard Mikke]

On the other hand, if editing software checked for some particular
software, the bot would have nothing to do.
So, maybe the bot is a good temporary solution until the map editors have
it implemented?
Also, it would be a good way to detect edits with new software that hes no
checking implemented.

On 4 April 2018 at 17:08, john whelan  wrote:

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


-- 
--
http://tnij.com/WyszukiwarkaRowerowa http://jolanta.korwin-mikke.pl/
r.mi...@pl.vwfsag.deryszard.mi...@gmail.com

دراجة أكبر
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Martin Koppenhoefer]

sent from a phone

> On 15. Apr 2018, at 14:04, Lena Essig  wrote:
> 
> mir ist aufgefallen, dass bei der Suche nach "emergency"="ambulance_station"
> nicht nur Rettungswachen angezeigt werden, sondern auch Bergwachten oder
> auch Ortsvereine.



würdet ihr emergency=ambulance_station auch für Leitstellen (mit Krankenwägen) 
verwenden, die nicht den Rettungsauftrag haben (i.e. qualifizierte 
Krankentransporte machen), oder müssen das Rettungswachen sein (funktional, 
d.h. sie sind aktuell mit Rettungsdienstaufgaben beauftragt)?

Gruß, 
Martin 




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

Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Daniel Korn]

Am 15.04.2018 um 14:04 schrieb Lena Essig:

Hallo zusammen,

mir ist aufgefallen, dass bei der Suche nach "emergency"="ambulance_station"
nicht nur Rettungswachen angezeigt werden, sondern auch Bergwachten oder
auch Ortsvereine.
Nur sehr wenige der Bergwachten sind mit "amenity"="mountain_rescue"
getaggt.
Es sieht tatsächlich so aus, als gäbe es einige Bergwachten, die wie 
eine Rettungdienst-Wache gemappt sind. Insgesamt finde ich 49 Kandidaten 
in Deutschland [1] von denen der Großteil zumindest in Süddeutschland 
definitiv zur Bergwacht gehören.

Da Bergwachten nur besondere Einsatzarten übernehmen, sollten sie von
normalen Rettungswachen unterschieden werden. Ebenso Ortsvereine der
einzelnen Hilfsorganisationen, da sie nichts mit dem Rettungsdienst zu tun
haben.


Zum Tag "amenity=mountain_rescue" konnte ich keine Dokumentation finden, 
ebensowenig zu "emergency_service=mountain" [2].


Sollte man in diesem Fall einfach diese bereits verwendeten Tags 
weiternutzen und damit de facto etablieren?


Gruß
Daniel

[1] http://overpass-turbo.eu/s/xU6
[2] https://www.openstreetmap.org/way/293933740

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

Re: [Talk-dk] Nyt script til addresseopdateringer

[Michael Andersen]

> 
> Steffen Møller/AWSbot "eksporterede" jævnligt diverse "fremmede" tags fra
> osak adressenoder. Eksempler i Århus: https://overpass-turbo.eu/s/xTn
> 
Hmm. Søgningen https://overpass-turbo.eu/s/xTX virker bedre :-/


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

[Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Lena Essig]

Hallo zusammen,

mir ist aufgefallen, dass bei der Suche nach "emergency"="ambulance_station"
nicht nur Rettungswachen angezeigt werden, sondern auch Bergwachten oder
auch Ortsvereine.
Nur sehr wenige der Bergwachten sind mit "amenity"="mountain_rescue"
getaggt.
Da Bergwachten nur besondere Einsatzarten übernehmen, sollten sie von
normalen Rettungswachen unterschieden werden. Ebenso Ortsvereine der
einzelnen Hilfsorganisationen, da sie nichts mit dem Rettungsdienst zu tun
haben.
Wie ist denn die allgemeine Regelung für Orstvereine oder
Katastrophenschutzzentren?

Solltet ihr mal über Bergwachten die als Rettungswachen getaggt sind
stolpern könntet ihr sie ja korrigieren um ein einheitliches Bild zu
bekommen.
Danke im Vorraus.

Grüße
Lena
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[OSM-talk-fr] SotM-fr / Les événements marquants 2017 pour OSM

[Vincent Bergeot]

Bonjour,

en préparation d'un doc pour les collectivités, pour le SotM-france, je 
voudrais connaitre, selon vous, les points importants depuis juin 2017 
dans la communauté OSM :


 * à un niveau international
 * à un niteau national
 * voire à un niveau bordelais-girondin !!

En vous remerciant pour vos suggestions :)

--

Vincent Bergeot

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

Re: [OSM-ja] 高速道路の定義について

[Ryosuke Amano]

横浜のあまのです。

muramoto様、取りまとめありがとうございます。
賛否投票は以下の通りでお願いいたします。

名前：あまの（Ryo-a）
*提案1：〇
*提案1-1：〇
*提案1-2：×
*提案2：〇
（ただし些末な分類するのではなく、「道路標識、区画線及び道路標示に関する命令」六）　車両の種類の略称　に規定される、各車両の種類および略称が、 
accessタグの車両種別のどれにあたるのか分類することを目的とする）

*提案3-1：〇
*提案3-2：×
*提案3-3：×
*提案4：〇
*提案5：〇

提案2以外の理由は、以前に長々とですが意見を述べた通りです。

提案2の理由は、これも以前に意見しましたが、現地の交通標識へどのように記載するかは、都道府県公安委員会に任されているからです。ただこの政令の略称は、
「規制標識に車両の種類を記載するときは、(中略)、それぞれ同表の下欄に掲げる略称を用いることができる。」とあり、全国的な共通性があるからで、この点だけは共通化できるであろうという考えからです。

道路標識、区画線及び道路標示に関する命令
http://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?lawId=335M50004002003=1

よろしくお願いいたします。

あまの


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

Re: [Diversity-talk] [HOT] Diverse conferences need you!

[Blake Girardot HOT/OSM]

Hi Rory,

Thank you very much for all your help with the CoC.

I was hoping we could put together another resource that is practical
advice for LGBTQ travellers.

You offered some good advice that I would never think of, empty your
phones of potentially problematic apps or content.

I read on the State Department one tip that said be wary of
entrampment type schemes with people trying to trick someone into
revealing info that would get them in trouble with the law.

I looked on a few gay travel websites, but most of their practical
advice consisted of saying know the local laws and check with the US
or other national foreign affairs office for their advice.

Could we somehow collaborate on a blog post that would offer some more
practical advice, all the helpful details and advice that can't really
go in the CoC but still would be helpful to folks.

Just a thought, if you think you would have time to contribute I can
make a shared google doc to just start the advice list or something.
But i do not have much to add besides stuff I can find spread around
the Internets, you seemed to have a lot of good advice I think would
be good to share.

regards,
blake

On Sat, Apr 14, 2018 at 12:40 PM, Rory McCann  wrote:
> Hi,
>
> An additional way to help out is on the FOSS4G github, where there are 2
> issues for the CoC & travel advice, where you can leave comments, and
> see the draft documents. Most of my suggestions have been taken on board.
>
> https://github.com/foss4g2018/foss4g2018/issues/65
> https://github.com/foss4g2018/foss4g2018/issues/64
>
>> all future events happening in countries with similar local laws to
>> Tanzania
>
> Can you please state in what (limited!) circumstances (parts of) the HOT
> CoC are optional, or run the risk that CoC opponents using any reason
> they want to have an event with a CoC with lots of "opt-outs", claiming
> "cultural differences".
>
> My suggestion: "No events where homosexuality is illegal if
> homosexuality/etc is legal in one part of the region for this event."
> (there might be other cases).
>
> Rory
>
> On 12/04/18 23:41, Rebecca Firth wrote:
>> Hi
>>
>> The HOT and FOSS4G community have been working hard to develop the
>> conference Code of Conduct for the upcoming event in Tanzania
>> (http://2018.foss4g.org/). The goal is to ensure the conference is as
>> welcoming and safe as it can be, and maintain a commitment to diverse
>> and inclusive conferences. Part of this means hosting conferences in
>> countries where HOT works as an organisation and where there are strong
>> local OSM communities. However, this does raise important concerns about
>> safety and security for attendees. We hope a re-drafted CoC will help
>> all future events happening in countries with similar local laws to
>> Tanzania, to ensure they can protect the interests and security of
>> attendees as best as possible. SOTM Africa, future, SOTMs, etc etc..
>>
>> The Summit/FOSS4G Working Groups have a re-drafted policy and would love
>> feedback from an as-diverse-as-possible group. If you're keen to
>> support, please get in touch with Amelia and Rachel in copy, who will
>> send you a copy of the policy and gladly hear your feedback.
>>
>> Thanks,
>>
>> Rebecca
>>
>> --
>> *Rebecca Firth*
>> Community and Partnerships Manager
>> rebecca.fi...@hotosm.org 
>> @RebeccaFirthy
>>
>> *Humanitarian OpenStreetMap Team*
>> *Using OpenStreetMap for Humanitarian Response & Economic Development*
>> *
>> *
>> You can #mapthedifference today! Donate.hotosm.org
>> 
>> web  | twitter  |
>> facebook  | donate
>> 
>>
>>
>>
>> ___
>> Diversity-talk mailing list
>> Code of Conduct: 
>> https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
>> Contact the mods (private): diversity-talk-ow...@openstreetmap.org
>>
>
> ___
> HOT mailing list
> h...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot



-- 

Blake Girardot
Humanitarian OpenStreetMap Team

___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-ja] 高速道路の定義について

[yuu hayashi]

hayashiです

提案3-4と提案3-3の違いについてですが、単純に表記法のちがいです。
「歩行者、軽車両通行止め」というのは日本の交通表記上の表現で、特に「軽車両」に該当するOSMのTAGがありませんので、OSMのmotorroad=yesの定義をするならばOSMの用語で定義する必要があると思います。
そのため、「歩行者、軽車両通行止め」をOSMのTAGで表現して、「access=no、motor_vehicle=yes」とするか日本語として、「自動車のみ」または「動力のある車両のみ」とするべきと考えます。

提案１についてですが
「高速道路ナンバリングされた道路」や「高規格幹線道路」「都市高速道路」などは路線全線に関する属性なのでリレーションに割り当てるべき属性だと考えます。
現行でもリレーションでマッピングされていますが、各路線の種別を識別するTAGやキーが設定されていないのでその識別キーを決めるのも重要なことと思います。

WAY：highway=motorway についてですが 「自動車専用道路」は「国で最高品質の道路」とみなすことができます。
少なくとも、普通の一般国道よりも「高品質の道路」となることは確実です。
単に「国道」を表すならリレーションで表現するのが妥当ですが、国道であっても個別の区間は「国で最高品質の道路」になっている場合が有ります。
例えば[国道１６号線保土ヶ谷バイパス](
https://ja.wikipedia.org/wiki/%E5%9B%BD%E9%81%9316%E5%8F%B7#%E3%83%90%E3%82%A4%E3%83%91%E3%82%B9)
は、制限速度８０km/h 片側３車線で無料の「自動車専用道路」です。
一方、[高速自動車国道の路線を指定する政令](
http://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?lawId=332CO000275)にある[道東自動車道](https://ja.wikipedia.org/wiki/%E9%81%93%E6%9D%B1%E8%87%AA%E5%8B%95%E8%BB%8A%E9%81%93)
の「本別ICー阿寒」は
片側１車線の対面通行、70km/h の無料の「自動車専用道路」です。
道路の品質だけ見れば、[横浜新道](
https://ja.wikipedia.org/wiki/%E6%A8%AA%E6%B5%9C%E6%96%B0%E9%81%93)の「今井IC」以西部分は「自動車専用道路」ではないが有料で
70km/h で分離通行になっている「横浜新道」のほうが「道東自動車道」よりも明らかに高品質です。
また、「首都高速」も開通当初は「最高品質」でしたが、ほぼ全線が60km/h で車線も狭く 現在の基準ではとても「最高品質」とは言いがたいです。

日本の「自動車専用道路」は単純に「歩行者、軽車両通行禁止」ではありません。
橋の幅が狭くて自転車などが通行するのが危険なために歩行者専用道路を併設したような場合には「歩行者、軽車両通行禁止」としますが「自動車専用道路」とはしません。（具体例：国道6号四つ木陸橋
https://goo.gl/maps/qHV59CfAvY32 ）
「自動車専用道路」は「小型二輪」を排除してまで高速車の通行品質を確保した道路といえます。

上記のことから、「自動車専用道路」は「国で最高品質の道路」とみなすことができるといえます。ちなみに

「歩行者、軽車両通行禁止」（motorroad=yes）と「自動車専用道路」との見分け方は小型自動二輪が通行できるかどうかで判別できます。

※「自動車専用道路」の標識があれば 小型自動二輪は通行できません。
なぜならば「日本には小型自動二輪通行可」を示す標識がないため、「自動車専用道路」の標識と補助標識で「許可」を併設することができないからです。

問題は「歩行者、軽車両、原付、小型二輪」が通行できなくても「自動車専用道路」の標識がない場合です。例：[小田厚の平塚IC以西](
https://ja.wikipedia.org/wiki/%E5%B0%8F%E7%94%B0%E5%8E%9F%E5%8E%9A%E6%9C%A8%E9%81%93%E8%B7%AF
)。
小田厚の場合は平塚IC以東は「自動車専用道路」の標識がありますが、平塚IC以西からは「二輪の二人乗りが禁止」のため「自動車専用道路」とは条件が変わるため「自動車専用道路」の標識がありません。(Wikipediaの記述は間違っています)
OSM的には「二輪の二人乗の可／不可」を考慮する必要はないので、

※「歩行者、軽車両、原付、小型二輪」が通行できなければ「自動車専用道路」とみなす
でいいと思います。
（いろいろな路線のケースを調べましたがこの法則で問題ないと考えています。これは[Wikipedia](
https://ja.wikipedia.org/wiki/%E8%87%AA%E5%8B%95%E8%BB%8A%E5%B0%82%E7%94%A8%E9%81%93%E8%B7%AF)
に記述とも合致します）
最終的に「歩行者、軽車両、原付、小型二輪」が通行できない区間を「自動車専用道路」とするかどうかの条件に「高速道路ナンバリングされた道路」や「高規格幹線道路」「都市高速道路」であるかどうかを加える必要があるかもしれません。

※「小型二輪」が通行できれば「自動車専用道路」としない
これも、いろいろなケースで考えてみましたがこうすることでOSM的にも現実的にもすんなりすると思います。
唯一、問題となるケースは[横浜新道](
https://ja.wikipedia.org/wiki/%E6%A8%AA%E6%B5%9C%E6%96%B0%E9%81%93)の「今井IC」以西部分と考えられますが、ここはWikipediaにもあるように「自動車専用道路」ではないので
highway=trunk にすべきだと思います。

上記のことから
 WAY: highway=motorway に「自動車専用道路」を割り当てることで、明確な識別が可能になると考えます。

また、
 * [JA:Tag:highway=motorway](
https://wiki.openstreetmap.org/wiki/JA:Tag:highway%3Dmotorway)にも矛盾しない

。
 * 「自動車専用道路」をタギングできる --> カーナビのデータとして非常に重要なPOIです。
 * 既存のJapanTaggingを踏襲できる --> 今までのデータが無駄にならない
の利点があると言えるでしょう。


*提案2
についてですが、
現在、accessタグについてまとめようとしていますが、
私は、大型免許を持っていないので、日本の大型、中型、貨物などの車種別種類の洗い出しに苦労しているところです。

とりあえず、私の興味のある範囲で決めて欲しいのは
moped=yes/no --> 「小型自動二輪」
mofa=yes/no  --> 「原付」
  agricultural=yes/no --> 「小型特殊」
です。

それと、私も生活が有りますので、毎日メールをチェックできるわけではありませんし、各人の意見もちゃんと調べる必要があるのでここに発言するにも時間が必要です。
本業の傍らやっているのと、休日も家族サービスという責務を縫ってやっていることをご理解いただきたいと思います。
私以外の他の方も同様の状況だと思いますので、進行日程に余裕をもたせるとかのご配慮をいただけるとありがたいです。



4/14改定
-
*提案1 日本のmotorwayの定義をJapan taggingに記載された内容から変更する。
*提案1-1 日本のmotorwayの定義を、(1) 高速道路ナンバリングされた道路(高規格幹線道路を含む)、(2) 都市高速道路 または
東京高速道路とする。(muramoto?)
*提案1-2 日本のmotorwayの定義を、(1) 高規格幹線道路、(2) 都市高速道路 または 東京高速道路とする。(Ras and Road)

*提案2 accessタグの車両種別について日本での定義を取り決める(hayashi)

*提案3-1 motorroad=yesの定義を「自動車専用道路」標識がついた道路とする(muramoto)
(補足：提案3-1を採用した場合、提案1-1または1-2の定義から外れたmotorwayは、trunk/primary +motorroad=yes
に置き換えることになる)
*提案3-2 motorroad=yesの定義を「歩行者、自転車通行止め」の道路とする(zyxzyx,
https://forum.openstreetmap.org/viewtopic.php?pid=690508)
*提案3-3 motorroad=yesの定義を「歩行者、軽車両通行止め」の道路とする(提案3-2の派生)

*提案4 道路運送法に基づく自動車道（アネスト岩田ターンパイクなど）は日本のmotorwayに含めない。(Ras and Road)

*提案5 道路運送法に基づく自動車道には、県道路公社の管理であっても県道ではない道路がある。これはtertiaryとする。(Ras and Road)
-



2018年4月14日 1:14 tomoya muramoto :

> みなさま
>
> これまでの議論で各提案の位置づけがなされたと思います。
> つきましては賛否投票を開始いたします。
> 4/21を一次締め切りとし、各提案に対して賛否を〇×で投票ください。とりあえず私の意見をサンプルとして挙げておきます。
>
> 名前：muramoto
> *提案1：〇
> *提案1-1：〇
> *提案1-2：×
> *提案2：〇
> *提案3-1：〇
> *提案3-2：×
> *提案3-3：×
> *提案4：〇
> *提案5：〇
>
> ※必ずしもすべての提案に対して投票する必要はありません。一部への投票でもOKです。
> ※サブ番号が付いた提案に対しては、いずれか一つに〇をつけてください。
> ※「提案3-4」は今回除外させていただきました。hayashi様からお返事いただけておらず、提案3-3との差異が明確にで
> きなかったためです。なおmotorroadの定義が決定後に、hayashi様の案を含め、具体的なタグの検討をおこないます。
>
> 4/14改定
> -
> *提案1 日本のmotorwayの定義をJapan taggingに記載された内容から変更する。
> *提案1-1 日本のmotorwayの定義を、(1) 

[Talk-es] Propuesta: cambiar la categoría de algunas carreteras nacionales en base a su uso y estado actuales.

[yo paseopor]

Al hilo de una "batalla" (en la que un usuario experimentado me insultó y
lo dejé por imposible) vuelvo a la carga con un tema simple: la necesidad
de que toda carretera no transferida y que dependa del Ministerio de
Fomento del Gobierno de España (nacional) no necesariamente haya de ser
trunk.

Rationale

Basta con mirar la wiki para darse cuenta de que la definición de trunk no
encaja con algunas carreteras nacionales en algunos de sus tramos. Además ,
si miramos a nuestro entorno la cuestión ha cambiado algo desde que lo
hablamos la última vez, países que habían tenido todas sus carreteras
"Nacionales/Estatales/..." pintadas de rojo (el color de trunk en OSMCarto)
ya han distinguido básicamente entre aquellas que son importantes de verdad
(y que suelen estar desdobladas la gran mayoría) y las que no.Si miramos a
un zoom 7 no es que nuestros países vecinos se hayan quedado vacíos e
incomunicados de infraestructuras, es que el render no muestra estas vías
básicas pero no preferentes hasta el render 8 en que además empiezan a
mostrarse también las vías de ferrocarril y otras infraestructuras básicas
que del 8 hacia atrás no salen.

Mirando nuestro entorno vemos que:

Portugal: La clasificación de vías se basa en itinerarios y no en las
Estradas Nacionais
Andorra: En Andorra no hay una sola carretera trunk ni siquiera que enlace
desde otros países...bueno, sí, hay una , adivinad de qué país viene.
Francia: Hay Routes Nacionales que no lo son.
Bélgica: No todas las N guardan la misma categoría
Holanda: Igual caso en Holanda
Austria: En Austria las B , las que van después de las A, no acostumbran a
ser trunk.
Alemania: Mirando un poco por encima veo que las que son trunk son aquellas
que son autovías.
Italia: Solo algunas Stradas Stradales son trunk (aún a riesgo de dejarte
en sus baches las ruedas)
Suiza: Carreteras principales como la 1 , que atraviesa el país de punta a
punta no son trunk y el único motivo en general por el que pasarías por
ellas es para saltarte la viñeta (el impuesto que se paga por acceder a las
autopistas.)
Reino Unido: No todas las A son trunk, como tampoco todas sus autovías
merecieran llamarse así (con semáforos, con rotondas...)

-Tiene sentido también, la gran mayoría de autovías en nuestro país se han
hecho resiguiendo recorridos de muchas nacionales, cuando no desdoblando la
misma nacional haciendo desaparecer su trazado original.
-De igual manera ya hace años por suerte que las vías importantes de cada
comunidad autónoma que cumplen ciertos requisitos de preferencia (suelen
ser vías nuevas,fuertes inversiones hechas por estas, sin cruces a nivel,
con una velocidad que oscila entre los 80 y los 100 km/h y que suelen tener
un mantenimiento óptimo) ya son consideradas trunk por el mapa y la
comunidad. ¿Entonces por qué una vía que no cumple con esos mismos
requisitos debe ser considerada trunk? ¿Simplemente por pertenecer a una
administración u otra? Aunque suene raro estos días recordemos que todas
las administraciones son estado (las comunidades autónomas gozan de
estatutos de autonomía aprobados en el Congreso de los Diputados con rango
de Ley Orgánica y sancionados por el rey). Por lo que este hecho no debería
ser significativo para que una vía gozara en el mapa de más o menos
visibilidad sino que habría que seguir otros criterios más acordes con la
conducción y el transporte.

-A riesgo de lo antiestético que pueda ser que el mapa quede a trozos...
¿es que un buen ruteador no sabe distinguir más allá de la categoría de la
carretera? ¿Es que nos vamos a fijar en la estética? ¿Es que eso no sería
mapear para el render? ¿En los otros países en los que eso pasa hay
problemas para usar navegadores GPS?

-También a riesgo de considerar algunos determinados ejes como de suma
importancia por el "simple" hecho de reseeguir determinado accidente
geográfico pensemos en si gozan al lado de una vía alternativa ,aunque esta
sea de pago (sigue siendo una vía alternativa , y de hecho hoy en día en
muchas de estas vías hay acuerdos para desviar el tráfico pesado por o que
su importancia ha bajado). Otros ejes no han gozado precisamente de
uniformidad en sus inversiones , mientras que tenemos tramos desdoblados
hay otros tramos que sólo se usan de forma lúdica y paisajista (me gustaría
preguntar de la lista cuantos usan el Eje Pirenaico de cabo a rabo, y lo
mismo digo para las carreteras que formaban el Eje Cantábrico o el Eje
Mediterráneo) por algún motivo que no fuere el económico existiendo una vía
alternativa.

-Recordemos también que eso nos trae ciertos problemas al mapear para otros
vehículos que no son coches y que según la mayoría de softwares basados en
OSM no tienen permiso para circular por trunks, evitando rutas principales,
que aunque peligrosas sí usan los ciclistas.

Por eso hago una propuesta a la comunidad española de OSM y por ende a
todos los demás grupos: que cada comunidad de OSM perteneciente a sus
respectivos territorios analice qué tramos (ya sabemos que en España las

Re: [Talk-de] natural in natural / natural in landuse / multipolygon?

[Martin Koppenhoefer]

sent from a phone

> On 14. Apr 2018, at 23:29, Garry  wrote:
> 
> Das ist das was meiner Meinung nach bei OSM von Anfang an etwas schief 
> gelaufen ist:
> Man hat häufig gleich zu spezielle Tags eingeführt anstatt den Oberbegriff zu 
> wählen um den dann genauer zu spezifizieren.


ich würde das etwas allgemeiner sehen, es gibt beide Fälle, „zu spezifisch“ und 
„zu unspezifisch“, bei tags. Beides sind natürlich bereits subjektive 
Wertungen, die man nicht zwangsläufig teilen muss, es ist immer relativ und 
hängt von den Interessen desjenigen ab, der die Bewertung vornimmt.

Was man aber schon beobachten kann, dass die Werte für einen key nicht immer 
derselben Klasse bzw. nicht in demselben Detaillevel sind (z.B. landuse 
residential und industrial vs. greenfield und brownfield; farmland und 
Unterklassen wie orchard und meadow auf selber Ebene, oder bei place: 
place=farm, vs. isolated_dwelling, ...). Beispiele für zu unspezifisch sind 
m.E. z.B. historic=ruins, amenity=social_facility, tourism=information (seit 
das auch Wegweiser und Infotafeln einschließt), public_transport=platform (weil 
das nicht nur Bahnsteige einschließt sondern alle Orte wo nahe eines 
stoppunktes auf öpnv gewartet wird).


Was ein Oberbegriff ist, und welche Unterschiede man „in erster Ebene“ bereits 
unterscheiden will, hängt eben davon ab, was man darstellen will, bzw. sucht. 
Sehr spezifische tags führen dazu, dass der Auswerter viele unterschiedliche 
tags betrachten muss, wenn man dagegen nur grobe tags hat ist die Darstellung 
ggf. weniger aufwendig, dafür vielleicht aber insgesamt nutzlos weil 
essentielle Unterschiede nicht dargestellt sind. Es besteht allerdings die 
Gefahr, dass solange es nur ein paar, sehr spezielle tags dokumentiert gibt 
(und für viele Dinge noch keine Festlegung getroffen wurde, bzw. sich  nichts 
herauskristallisiert hat), manche Mapper evtl. versuchen, unpassende Objekte in 
diese spezifischen tags zu pressen, weil es „dem noch am nächsten kommt“, 
obwohl der tag vielleicht unpassend ist (amenity=arts_centre war so ein 
‚Joker‘-tag, oder landuse=village_green oder grass).

Gruß,
Martin 



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

[OSM-talk-fr] hebdoOSM Nº 403 2018-04-03-2018-04-09

[weeklyOSM -]

Bonjour,

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

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

Bonne lecture !

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

Re: [Talk-dk] Nyt script til addresseopdateringer

[Jonathan Hougaard]

Hej Ole


Du har ret i det kunne være en fordel at tage hensyn til ekstra tags når 
en adresse bliver slettet. Egentlig havde jeg planer om en "naiv" 
tilgang hvor knudes simpelthen bliver slettet, hvis adressen ikke 
længere eksisterer. Det er klart det nemmeste og mindst resourcekrævende 
at lave. Men i princippet kan funktionen til sletning af adresse godt 
laves anderledes, noget ala: hent hver knude med adresse der skal 
slettes, scan alle tags igennem, hvis knuden kun indeholder kendte 
adressetags - slet noden - ellers fjern blot kendte tags. Der er uden 
tvivl faldgruber ved begge metoder. Ved den "naive" tilgang risikerer vi 
at miste data i form af ekstra tags på adresseknuder. Jeg ved ikke, hvor 
almindeligt det er, at der er tilføjet ekstra tags, og hvor meget data 
der i så fald er tale om. Omvendt risikerer vi at ende med knuder med 
tags, der måske ikke giver ret meget mening alene, hvis nogle tags blot 
fjernes og knuden efterlades. Eks. en adresseknude hvor der er tilføjet 
et "note" tag, hvilket så vil være det eneste tilbageværende tag efter 
en sletning.


Jeg har ikke planer om at lave en større validering af data fra DAR. Så 
bliver det lige pludseligt et kæmpestort, og for mig uoverskueligt, 
projekt. Hvis en adresse ifølge DAR ligger i en sø, så ligger adressen i 
en sø. Data fra DAR har været af god nok kvalitet til at vi har 
importeret det til OSM siden 2009, og jeg tillader mig derfor den 
antagelse, at det stadig er tilfældet. Hvis vi ikke kan stole på vores 
ene datakilde, falder hele projektet til jorden.



On 15/04/2018 07:32, Ole Laursen wrote:

Et skridt ad gangen, men nogle tanker:


Nu er det et stykke tid siden jeg har rodet med adresser i OSM (for
mange små børn og for lidt søvn), men i mine øjne bør vi have en lille
dokumentation af hvad botten kan finde ud af med hensyn til
interaktion med manuel kortlægning.

F.eks. bør den kunne finde ud af at flette oplysningerne korrekt
sammen hvis nogen har tilføjet ekstra tags. Hvis adresseknuden senere
forsvinder fra det officielle register, bør den jo nok også lade være
med at slette sådan en knude men i stedet bare slette osak-tagsn'e.

Vi bør også have en måde at rette åbenlyst forkerte adresser. Jeg
biksede i sin tid denne side sammen

https://oisfixes.iola.dk/

som kan håndtere forkerte vejnavne. Men der kan være andre ting galt,
f.eks. koordinaterne. Jeg har i sin tid set adresser ude i en sø,
eller adresser der ligger oven i hinanden i en boligforening med
rækkehuse.

Det skal kommunerne fikse, men det dur ikke at vi har en løsning hvor
data i OSM er forkerte indtil en eller anden ved en kommune måske
eller måske ikke retter noget til.

Om det er lettest at have et system hvor vi tagger knuderne i OSM
eller jeg skal tage mig sammen til at udvide oisfixes som jeg nu har
lovet i flere omgange, ved jeg ikke?


Ole

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



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

Re: [Talk-dk] Nyt script til addresseopdateringer

[Jonathan Hougaard]

Hej Mikkel


Tak for link. Jeg har kigget dine issues igennem og kan konstatere, at 
der ikke umiddelbart er nogen, der går igen i min foreløbige kode.


Jeg vil som sagt gerne dele kildekoden, men så længe projektet er i et 
tidligt stadie hvor store dele af koden hurtigt kan ændre sig, ser jeg 
det ikke som en fordel at bruge tid på at uploade rettelser hvert andet 
øjeblik. Når den grundlæggende struktur er på plads skal den nok blive 
uploaded, don't worry.


Spørger du fordi du kender til import-platforme, der kan bruges - eller 
er det et reelt spørgsmål? Hvis du kender noget, der kunne være 
relevant, håber jeg selvfølgelig, at du vil dele det.



On 14/04/2018 13:33, Mikkel wrote:

Hej Jonathan.

Fedt endelig at se noget interesse og initiativ til at forbedre 
DAR-importen (aka. DAWA/AWS), det kan jeg kun bakke op om.


Jeg har ikke så meget tid til at uddybe lige nu, men har også studeret 
og eksperimenteret med det eksisterende AWSbot, og begyndt at 
forberede noget lignende det du beskriver. Jeg tænkte dog oprindeligt 
at prioritere at få scriptet i en tilstand så Stephen i første omgang 
kunne fortsætte med hans normale procedure, inden der blev kigget for 
meget fremad. Det virkede dog som om han mistede interessen, og så 
vidt jeg kan se har han trukket sig helt, så jeg har valgt at bruge 
tiden på at blive klogere i stedet for at implementere nødløsninger.


Jeg har et AWSbot-fork på https://github.com/mikini/AWSbot/, hvor jeg 
har tilføjet issues med de problemer jeg har observeret i det 
eksisterende script. Hvis du har taget udgangspunkt i det, vil det nok 
være en ide at kaste et blik på dem.


Det er fint at du spørger til input, samarbejde og konsensus er efter 
min mening helt nødvendigt, men input er ikke nok. Processen og en 
forbedret importer bør være så åben og transparent som mulig, så vi 
kan skabe så fleksible og interoperable værktøjer til os selv som muligt.
Jeg synes bestemt ikke det er i orden at kildekode først frigives når 
der foreligger en endelig version. Et så centralt værktøj skal 
udvikles i det åbne af og i fællesskabet og være under en fri software 
licens.


Har du studeret om der findes en "import-platform" fra OSM eller andre 
regioner man kunne bygge videre på?


Bemærk at Apple som også annonceret her, 
https://lists.openstreetmap.org/pipermail/talk-dk/2018-March/004995.html, 
har vist interesse for data i Dansk OSM, herunder også importeren. Vi 
er nogle stykker der har haft en snak med dem om tilstanden af 
DAR-import i deres issue for Danmark, se 
https://github.com/osmlab/appledata/issues/69#issuecomment-370098972.
Jeg har kommunikeret lidt med OSM-projektlederen fra Apple, og det er 
mit indtryk at de også godt kunne være interesserede i at sponsorere 
noget arbejde på at forbedre importeren.


Hilsner,
Mikkel

Den 14. april 2018 09.45.50 CEST, Jonathan Hougaard 
 skrev:


Hej alle


Efter en kort diskussion her:
https://www.openstreetmap.org/changeset/57976035  har jeg besluttet mig
for at give mig i kast med at bygge en ny web app, der kan bruges til at
vedligeholde danske adresser vha. det danske adresseregister.


Grundstrukturen er allerede funktionel, men før jeg arbejder videre med
projektet vil jeg gerne have spørgsmål, kommentarer og ønsker til
projektet. Grundlæggende er ideen at opdatere adresser på en måde
svarende til den vi kender fra AWSbot scriptet. Den tekniske del er dog
lavet fra bunden, og virker på en noget anden måde end AWSbot, hvilket
gerne skulle give en mere effektiv og fleksibel databehandling.


Følgende wiki-side vil være primær dokumentation for projektet:
https://wiki.openstreetmap.org/wiki/AutoAWS.  Siden vil blive opdateret
løbende i takt med at jeg arbejder videre med projektet, baseret på
jeres kommentarer og ønsker. Kildekoden vil blive offentliggjort når en
endelig version af appen er færdiggjort.


Efterhånden som det hele skrider frem vil jeg nok have mere konkrete
spørgsmål at stille - men i første omgang vil jeg blot meget gerne høre
jeres umiddelbare indtryk, tanker, ønsker osv.


Allerede nu vil jeg melde ud, at hvis opdatering af adresser skal køre
fuldautomatisk (tanken er at hvert postnummer automatisk kan blive
opdateret hver 30. dag), vil det kræve noget serverinfrastruktur hvor
scriptet kan køre. Jeg bidrager gerne min tid og viden til projektet,
men er ikke interesseret i at bidrage økonomisk. Hvis der er nogen, der
kan bidrage med serverplads, hører jeg derfor gerne fra jer. Det er ikke
det helt store, der kræves - hvis du for eksempel har en personlig
hjemmeside, vil scriptet nok kunne køre i baggrunden på den.

Alternativt kan det hele også køre på en almindelig computer, hvis der
installeres noget server-software (f.eks. Wampserver). Så vil
opdateringen dog ikke kunne køre fuldautomatisk.


Foreløbigt ser jeg frem til at modtage tanker og kommentarer.