Re: [Talk-ca] Mapping of bilingual destination signs

[Matthew Darwin]

Thanks J.P.

If at some point there is a more clear boundary maybe someone could 
update the wiki https://wiki.openstreetmap.org/wiki/New_Brunswick to 
give the rest of us more clear guidance.



On 2017-10-03 12:16 AM, J.P. Kirby wrote:

On 2017-10-03, at 12:33 AM, Matthew Darwin  wrote:


Hi J.P.

This sounds reasonable.  Do we have a map that shows which areas of the 
province are French area vs English area.  For us non-NBers.   Or I suppose one 
could guess by looking at the existing tags there.  (I would assume Fredericton 
is English area?)  If we have a list then could update the NB wiki page. 
https://wiki.openstreetmap.org/wiki/New_Brunswick

The general rule is that southern and western NB is English, northern and 
eastern is French; but there are exceptions, and a couple places like Bathurst 
and Campbellton are 50/50.

But yes, you can almost always tell from the tags and the street names themselves (e.g. "St. 
Mary's" vs "Sainte-Marie").

JPK


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

Re: [Talk-ca] Mapping of bilingual destination signs

[Matthew Darwin]

Should we follow the convention that the local language does not need 
a language tag and the alternate language does.  So for Fredericton 
(or Ottawa), it is


destination=New Maryland
destination:street:fr=Rue Regent Sud
destination:street=Regent Street South
destination:ref=101 South

This way existing renderers that don't understand the language 
extension continue to work.


On 2017-10-09 03:52 PM, Martijn van Exel wrote:

Hi all,

I contacted the most active mappers in NB. It seems that mapping 
bilingual street destinations with destination:street:fr and 
destination:street:en respectively is an acceptable solution. So the 
exit way related to the image in our ticket 
(https://github.com/TelenavMapping/mapping-projects/issues/27) would 
be mapped as:


destination=New Maryland
destination:street:fr=Rue Regent Sud
destination:street:en=Regent Street South
destination:ref=101 South

(just destination tags, ignoring the other tags obviously needed)

As promised, I will update the OSM wiki to clarify the 
destination:street tagging some.


Does this sound okay to you?

Thanks for all your feedback.
Martijn


On Fri, Oct 6, 2017 at 3:36 PM, Martijn van Exel > wrote:


Hi all,

Thanks all for your input. I get a sense that there is a
preference for separating out the names on these destination
signs in separate language tags, even though documentation for
destination:street is sparse. To be sure I contacted what I hope
are the top mappers in NB. A list of mappers I contacted and the
message I sent is in the github ticket
(https://github.com/TelenavMapping/mapping-projects/issues/27
).
This is based on the Pascal Neis web site
http://resultmaps.neis-one.org/oooc
 .

It would be nice to update the NB wiki page with a French /
English map but I will leave that to the experts.

I will try and clarify the destination:street documentation on
the wiki next week.

Martijn

On Mon, Oct 2, 2017 at 10:16 PM, J.P. Kirby
> wrote:


On 2017-10-03, at 12:33 AM, Matthew Darwin
> wrote:

> Hi J.P.
>
> This sounds reasonable.  Do we have a map that shows which
areas of the province are French area vs English area.  For
us non-NBers.  Or I suppose one could guess by looking at
the existing tags there.  (I would assume Fredericton is
English area?)  If we have a list then could update the NB
wiki page. https://wiki.openstreetmap.org/wiki/New_Brunswick


The general rule is that southern and western NB is English,
northern and eastern is French; but there are exceptions,
and a couple places like Bathurst and Campbellton are 50/50.

But yes, you can almost always tell from the tags and the
street names themselves (e.g. "St. Mary's" vs "Sainte-Marie").

JPK


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






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

Re: [OSM-talk-fr] Publication OpenData du cadastre

[Philippe Verdy]

Le 11 octobre 2017 à 08:32, David Marchal  a écrit :

> Bonjour.
>
>
> Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les
> polygones des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ;
> apparemment, les bâtiments sont constitués d’une ligne dont le premier et
> le dernier point ont les mêmes coordonnées, mais ne sont pas le même point.
> Pour JOSM, le polygone n’est pas fermé.
>

Ce n'est PAS un bogue du GeoJSON fourni mais une limite de ce format qui ne
code pas les noeuds membres d'un way comme des entités séparées mais
représente les polygones fermés en indiquant seulement les même coordonnées
de fin que celle du début (ce n'est pas une obligation cependant car les
types "Polygon" et "MultiPolygon" d'un GeoJSON ne contiennent QUE des
chemins fermés pour représenter des surfaces, éventuellement avec des
"trous", et la fermeture est donc implicite; les chemins ouverts sont codés
en GeoJSON avec les types "LineString" ou "MultiLineString" pour les
graphes de lignes non nécessairement continues entre elles ; un "Polygon"
représente une surface connexe éventuellement trouée, un "MultiPolygon"
représente plusieurs de ces surfaces, par exemple des îles, y compris des
enclaves incluses dans une surface trouée et sans connexion de ces enclaves
avec la surface englobante)

Bref ce n'est pas une anomalie du fichier cadastral.

C'est plutôt un bogue (une limite) de l'extension d'import de GeoJSON, qui
crée des objets noeuds séparés pour chaque paire de coordonnées [x,y] dans
le GeoJSON sans les fusionner quand elles sont identiques.

C'est très facile à régler cependant: une fois le GeoJSON chargé, cliquer
sur "Valider" et le validateur de JOSM trouvera tous les noeuds superposés
créés par le plugin d'import de GeoJSON. Sélectionner ce groupe, et cliquer
sur "Corriger" pour fusionner un un clic ces noeuds.

Une autre limitation de l'import de GeoJSON dans JOSM est qu'un attribut
OSM "area=yes" n'est pas automatiquement ajouté à chacun des "Polygon"
GeoJSON importés: la surface importée devient alors une simple "ligne" dans
JOSM.

L'import de GeonJSON ne crée une relation OSM "type=multipolygon" que si un
des Polygon est "troué" (donc quand un "Polygon" contient plus d'un élément
dans son tableau "coordinates": le premier élément du tableau prendra dans
la relation créée par le plugin un rôle OSM "outer", et les suivants auront
un rôle OSM "inner"; dans un MultiPolygon, c'est le nombre d'éléments au
second niveau d'indice qui détermine si une relation OSM
"type=multipolygon" sera créée ou pas, un Multipolygone pouvant contenir
plusieurs "Polygon" troués ou pas...).

Pour un "MultiLineString" GeoJSON, le plugin d'import dans JOSM ne crée
aucune relation OSM "type=multipolygon", il crée juste des ways OSM séparés
(et là encore sans tenter de fusionner les noeuds superposés.

Bref GeoJSON représente différemment les géométries.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] Redacted roads in VIC QLD and WA

[Sam Wilson]

There are links to the WA roads datasets on
https://wiki.openstreetmap.org/wiki/Contributors#Western_Australia

 For both of them, you can load Landgate's WMS service with this URL:
https://services.slip.wa.gov.au/public/services/SLIP_Public_Services/Transport/MapServer/WMSServer
 (although note that there are lots of other datasets on that service,
 and you're not allowed to use most of them for OSM).
 I use JOSM, and it works pretty well. Just keep in mind that these are
 gazetted roads, and so may not actually match what's been built in
 either alignment or existence. :-)
 —Sam


On Wed, 11 Oct 2017, at 06:46 PM, Nick Hocking wrote:
> We have specific permissions to use certain QLD and WA data. Do we
> have any such permissions for VIC, or do we have anybody who knows
> who to ask?> 
> Also are there and tile servers or overlays for the QLD and WA data
> that we can use to manually get the redacted road names back easily?> 
> _
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [OSM-talk-fr] Nouvelle analyses Osmose sur la France : numéro de téléphone et intégration des restrictions de hauteur

[Philippe Verdy]

Le 11 octobre 2017 à 11:45, Raphael Jacquot  a écrit :

> On 10/11/2017 11:27 AM, Julien Lepiller wrote:
> [snip]
>
> > Des avis ?
>
> Bonjour
>
> [je suis opérateur télécom]
>
> le format des numéros en france est :
> EZABPQMCDU
> le format recommandé est:
> +33 Z AB PQ MC DU
>
> à noter les numéros donc ZAB = 700 sont plus longs, réservés aux modems
> mobiles :
>
> +33 Z AB PQ MC DU xx xx en métropole (P = 0 a 4)
>
> dans les départements d'outre-mer :
>
> +33 Z AB PQ MC DU xx x
>
> avec P:
> 5: Guadeloupe
> 6: Guyane
> 7: Martinique
> 8: Mayotte
> 9: La Réunion


Tu ne cites que les 5 DOM. Donc effectivement rien pour les COM (comme
Wallis-et-Futuna et la Polynésie française) et la Nouvelle-Calédonie où le
+33 n'est pas utilisé.
Et comme toi je suis d'avis de ne pas tout coller, et au minimum garder une
espace après le préfixe international (+33) et avant le numéro national à 9
chiffres (Z AB PQ MC DU)

En revanche les "xx" ci-dessus n'ont rien à faire avec le plan de
numérotation national, ce sont des chiffres d'extension (propres à l'abonné
pour la SDA, sélection directe à l'arrivée) et contrairement à ce que
certains ont dit ici, il n'y a PAS nécessité d'attendre une tonalité pour
les composer, le numéro entier est transmis vers l'abonné directement sans
même nécessairement à insérer la touche-code "*".

Si on a une SDA dans le numéro, il est conseillé de mettre une espace avant
(mais pas nécessaire si la SDA commence par une "*"). Cette SDA évite
devoir passer par une annonce d'accueil, un robot vocal ou un standard, on
joint le poste directement, ça sonne, et si ça répond pas ou si le poste
demandé est désactivé ou renvoyé, c'est l'autocom de l'entreprise qui
reprend l'appel pour l'emmener vers le poste de renvoi ou vers l'accueil
standard (dans certaines entreprises la SDA permet aussi un renvoi interne
vers un mobile, pratique pour les transporteurs, les personnels médicaux ou
de sécurité lors de leurs déplacements, l'entreprise elle-même paye le coût
du réacheminement depuis l'autocom de l'entreprises vers un de ses autres
postes itinérants). L'autocomm peut être externalisé (ces fonctions étant
fournies par l'opérateur télécom de leur choix).

Les numéros contenant des "*" et des "#" sont valides même en
international. Certains réseaux étrangers ne savent pas véhiculer la SDA en
entier: on ne change pas le numéro mais dans ce cas l'appelant appellera le
numéro sans ce suffixe, attendra que "ça décroche" puis composera la SDA
(c'est pour ça qu'une "*" est conseillée en tête de SDA pour passer outre
l'annonce d'accueil et naviguer directement sans l'écouter).

Cependant les SDA sont devenues plus rares en France où on ne manque plus
de numéros fixes et où les "standards" d'accueil disparaissent au profit
des centres d'appels avec leurs numéros spéciaux en "08" (ou numéros
courts+"dire un mot code"): il est facile d'assigner maintenant des numéros
fixes à 10 chiffres pour chaque poste et de les acheminer tous sur une
ligne groupée gérée par un même autocomm permettant les réacheminements
éventuels vers d'autres postes (et enfin il y a de moins en moins de
numéros de poste spécifique, les entreprises ayant besoin que leurs
personnels itinérants soient joignables les équipent aussi un téléphones
mobiles avec un numéro à 10 chiffres en 06 ou 07.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] autoroute à péage

[marc marc]

Bonsoir,

Merci pour vos avis.
J'ai fais un premier nettoyage

Le 05. 10. 17 à 07:33, David Crochet a écrit :
 >> en conséquence de la barrière mettre toll=yes
 >> et/ou fee=yes sur l'autoroute ?
 >> si oui quelqu'un connaît-il la longueur concernée ?
 > Longueur de tout ce qui engendre un paiement

Lapalisse n'aurait pas dit mieux :)
Ne la connaissant pas, je me suis contenté d'un toll
sur la section autour du péage.
Si quelqu'un a la connaissance locale ou a envie de sélectionner
manuellement (ou une requête overpass ?) les routes entre 2 péages, 
qu'il se fasse plaisir :)
Peut-être une suggestion pour osmose.

Le 05. 10. 17 à 10:19, Christian Quest a écrit :
> Le code postal sur la barrière, mais quel intérêt ? On va lui écrire ? 
à la barrière sûrement pas.
Au bâtiment peut-être, mais le CP étant faux, je l'ai supprimé,

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

Re: [talk-au] Qld topo map usable?

[Graeme Fitzpatrick]

Thanks for looking into that for us Simon.

As far as I can tell, with my limited legal knowledge, it all appears to be
down to interpretations of how CC / OSM on one side, & DNRM on the other,
are reading the same document - would that be right?

Could I ask if you, who understands the legals involved, could contact the
people from DNRM directly?

Thanks

Graeme

On 9 October 2017 at 21:28, Simon Poole  wrote:

> Hi all
>
> I was on the road the last two weeks so didn't see this thread, sorry.
>
> (Un-)luckily the situation is completely clear, we need the waiver as
> provided here https://drive.google.com/file/d/
> 0B3PN5zfbzThqeTdWR1l3SzJVcTg/view to be able to use the data in OSM.
> Even better: you don't even need to take my word for it, as the text here
> https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ was
> developed with feedback and input from CC (and I would consider CC fairly
> authoritative on matters of their licence).
>
> The underlying issue is that the ODbL, being pragmatic and practical,
> allows on the one hand distribution of the data via DRM protected means as
> long as there is a parallel distribution mechanism available (the more
> theoretical issue ) and on the other hand allows for works produced out of
> the data that are not databases (for example a map image) to be licensed on
> essentially any terms as long as the required is attribution provided.
>
> Simple example: a map image produced from OSM data can be incorporated in
> a cinematic production and distributed on a blu-ray disc or streamed via
> Netflix with DRM in place. Neither is possible with derivatives from CC BY
> licensed material.
>
> Simon
>
> Am 01.10.2017 um 08:24 schrieb Andrew Harvey:
>
> I made an enquiry to DNRM about this exactly back in June.
>
> The response I got was:
>
> We have given consideration to your request and advise that, consistent
> with Queensland Government policy, our data is provided under a CC:BY 4.0
> Licence.  The department will not provide the data under an ODbl licence.
> It is our belief that a CC:BY licence is sufficient for use of our data and
> we do not accept that OpenStreetMap cannot use our data under the CC:BY
> licence.
>
>
>
> If you have any questions or I can be of any further assistance please
> feel free to contact me by any of the methods below.
>
> So in the end I didn't get the waiver form OSMF requires, yet DNRM
> believes we can use CC BY 4.0 data in OSM without it, in conflict with what
> the OSMF says. I don't feel this is good enough, but I'm not a lawyer so I
> left it at that.
>
> If anyone can help pick this up again, I feel we have a good chance of it
> happening.
>
> DNRM are very responsive to enquiries like this, which is great.
>
>
> On 1 Oct. 2017 4:50 pm, "Andrew Harvey"  wrote:
>
> Unfortunately not. CC BY 4.0 data isn't compatible with the OSM license,
> see https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ for more
> details.
>
> There is a waiver form at that link which the copyright holder needs to
> agree and sign for CC BY 4.0 data to be used in OSM.
>
> Some Australian agencies have agreed to this, and others have explicitly
> not agreed to this, so it's hit and miss based on the agency.
>
> On 1 Oct. 2017 4:29 pm, "Graeme Fitzpatrick" 
> wrote:
>
>> G'day all
>>
>> I've just come across an online Qld topo map, published by Dept of
>> Natural Resources.
>>
>> Map is at http://qtopo.dnrm.qld.gov.au/Mobile/
>>
>> Also makes reference to copyright being licensed under CC BY 4.0:
>> https://www.dnrm.qld.gov.au/legal/copyright, & includes
>>
>> "Under this licence you are free to use this information in accordance
>> with the licence terms without having to seek permission from our
>> department. You must keep the copyright notice intact and attribute the
>> State of Queensland as the source of the material."
>>
>> Does that mean we can use it?
>>
>> Thanks
>>
>> Graeme
>>
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
>>
>
>
> ___
> Talk-au mailing 
> listTalk-au@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-au
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-it] Fire hydrant voting

[Alberto]

Scusate il doppio invio, mi è partita una mail con oggetto sbagliato.

> 1. perché dobbiamo cambiare il tag da "fire_hydrant:*" a "*" se ci 
> sono già millioni di questo tag, se non cambia nient'altro che togliere il 
> prefisso?

Innanzi tutto perché nella discussione diversi avevano proposto così e gli 
altri sembravano tutti d'accordo.
Ma soprattutto ci sono diversi tag che non sono specifici per gli idranti, 
quali pressure, location e diameter e quasi tutti quelli nuovi proposti 
(water_source, water_volume, couplings, couplings:type, couplings:diameters, 
ecc).
Forse per type si potrebbe anche mantenere il prefisso fire_hydrant:, ma si era 
scelto così per uniformare il più possibile.
Il diametro in realtà non è né quello interno né quello esterno, ma è quello 
nominale stampato sull'idrante, che è legato al diametro interno ma non vi 
corrisponde [1]. Nella pagina wiki finale questo verrà documentato a dovere, ma 
comunque era già una incompletezza del tag originale fire_hydrant:diameter=*. 
Il tag diameter=* invece è già usato in combinazione con man_made=pipeline ed 
ha esattamente lo stesso significato [2], cioè di diametro nominale. Quindi a 
nostro avviso era logico usare diameter=* anche per gli idranti e semmai è la 
pagina wiki di diameter=* che deve essere meglio definita per specificare che 
si tratta del diametro nominale.
Fire_hydrant:position=* ha esattamente lo stesso significato di location=*. 
Solo che location=* fin'ora non era usato per gli idranti e quindi mancano i 
valori tipici come green, sidewalk, lane, parking_lot. Anche qui ci sembrava 
illogico avere un tag che ha lo stesso uso di un altro e quindi abbiamo optato 
per usare il più generico location=*.
Per quanto riguarda i milioni di tag coinvolti, una volta stabilito cosa fare, 
non vedo grande differenza tra cambiarne 100 o 1.000.000, visto che si dovranno 
solamente selezionare tutti i fire_hydrant:pressure=*, fire_hydrant:diameter=*, 
 fire_hydrant:position=*, ecc. e sostituirli con pressure=*, diameter=*, 
location=*, ecc.
Insomma, la proposta così come la leggete è il risultato di mesi di 
discussioni, ricerche, confronti, correzioni e c'è una spiegazione per tutto. 
Ripeto, il nostro errore è stato quello di non riuscire a documentare tutto 
esaustivamente nella pagina della proposta (ma ci proponiamo di farlo nella 
pagina wiki definitiva), ma se la gente che ora vota contro avesse seguito le 
discussioni, ora capirebbe molte cose.

Ciao
Alberto

[1] https://it.wikipedia.org/wiki/Diametro_nominale
[2] http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpipeline


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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

[Talk-it] R: Digest di Talk-it, Volume 131, Numero 24

[Alberto]

> 1. perché dobbiamo cambiare il tag da "fire_hydrant:*" a "*" se ci sono già
> millioni di questo tag, se non cambia nient'altro che togliere il prefisso?

Innanzi tutto perché nella discussione diversi avevano proposto così e gli 
altri sembravano tutti d'accordo.
Ma soprattutto ci sono diversi tag che non sono specifici per gli idranti, 
quali pressure, location e diameter e quasi tutti quelli nuovi proposti 
(water_source, water_volume, couplings, couplings:type, couplings:diameters, 
ecc).
Forse per type si potrebbe anche mantenere il prefisso fire_hydrant:, ma si era 
scelto così per uniformare il più possibile.
Il diametro in realtà non è né quello interno né quello esterno, ma è quello 
nominale stampato sull'idrante, che è legato al diametro interno ma non vi 
corrisponde [1]. Nella pagina wiki finale questo verrà documentato a dovere, ma 
comunque era già una incompletezza del tag originale fire_hydrant:diameter=*. 
Il tag diameter=* invece è già usato in combinazione con man_made=pipeline ed 
ha esattamente lo stesso significato [2], cioè di diametro nominale. Quindi a 
nostro avviso era logico usare diameter=* anche per gli idranti e semmai è la 
pagina wiki di diameter=* che deve essere meglio definita per specificare che 
si tratta del diametro nominale.
Fire_hydrant:position=* ha esattamente lo stesso significato di location=*. 
Solo che location=* fin'ora non era usato per gli idranti e quindi mancano i 
valori tipici come green, sidewalk, lane, parking_lot. Anche qui ci sembrava 
illogico avere un tag che ha lo stesso uso di un altro e quindi abbiamo optato 
per usare il più generico location=*.
Per quanto riguarda i milioni di tag coinvolti, una volta stabilito cosa fare, 
non vedo grande differenza tra cambiarne 100 o 1.000.000, visto che si dovranno 
solamente selezionare tutti i fire_hydrant:pressure=*, fire_hydrant:diameter=*, 
 fire_hydrant:position=*, ecc. e sostituirli con pressure=*, diameter=*, 
location=*, ecc.
Insomma, la proposta così come la leggete è il risultato di mesi di 
discussioni, ricerche, confronti, correzioni e c'è una spiegazione per tutto. 
Ripeto, il nostro errore è stato quello di non riuscire a documentare tutto 
esaustivamente nella pagina della proposta (ma ci proponiamo di farlo nella 
pagina wiki definitiva), ma se la gente che ora vota contro avesse seguito le 
discussioni, ora capirebbe molte cose.

Ciao
Alberto

[1] https://it.wikipedia.org/wiki/Diametro_nominale
[2] http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpipeline



---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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

Re: [Talk-it] Tag wikipedia su via

[Marco_T]

Ciao Daniele,
concordo che è sbagliato in quanto l'oggetto mappato è la via, non il
personaggio a cui è dedicata.
Diverso sarebbe se la via avesse una denominazione particolare con un item
wikipedia riferito poroprio a quella specifica via, tipo queste:
https://it.wikipedia.org/wiki/Vie_di_Firenze
Consiglio di segnalare la cosa con un commento al changeset (magari
allegando un link a questa discussione), in questo modo il mappatore può
imparare qualcosa di nuovo e se non è convinto può chiedere spiegazioni o
motivare le sue scelte.

-- 
Marco_T



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

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

[Talk-it] Risposta: Risposta: Bicipolitana

[Lorenzo Mastrogiacomi]

Il giorno mer, 11/10/2017 alle 22.46 +0200, Gianluca Boero ha scritto:
> Grazie...tengo a mente i tuoi consigli per quando sarà realizzata
>   quella di Pinerolo.
> Si..concordo anche io come operator inserire il comune.
> Solo una domanda...il ref 3 corrisponde al terzo tratto?
> 
> 
> 

Si, ho messo come ref il numero della linea.


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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Massimiliano Guidi]

Il giorno mer 11 ott 2017 alle ore 18:48 matteocalosi <
matteocal...@gmail.com> ha scritto:

>
> Lo so che non si mappa per il rendering ma i renderer escursionistici non
> fanno in genere vedere i nomi delle relazioni sui sentieri (anche a ragione
> perchè visivamente il risultato non sarebbe spesso piacevole/utile, vedi
> l'esempio delle relazioni liguri) quindi aggiungere il nome di un sentiero
> sulla way è di fatto l'unico modo di vederlo. Se non fosse formalmente
> errata come cosa io preferirei aggiungerlo piuttosto che perdere la
> visualizzazione del nome dei soli sentieri che lo hanno ufficializzato.
>

Ma si che si mappa per il rendering, tu vai in giro per monti a fare query
da terminale con un laptop? ;-)

Seriamente, ci sono due problemi:
1) Il circolo vizioso: tu metti i nomi sulle way perché i renderer ignorano
le relazioni e i renderer continuano a ignorare le relazioni perché tanto
tu metti i nomi sulle way.
2) per il rendering le relazioni sono meglio, perché rappresentano il
sentiero nella sua interezza. La way prima o poi finisce invariabilmente
spezzata in enne segmenti in seguito alle variazioni di incline,
trail_visibility, sac_scale, mtb:scale, surface e quant'altro. Il
risultato, a meno di avere un renderer particolarmente sofisticato che
riunisce i segmenti in base al name, è che i nomi finiscono per non essere
visualizzati (oppure vengono troncati) perché ciascun segmento viene
trattato a sé ed è troppo corto per ospitare il nome.

Personalmente, nel mio piccolo, ignoro il name sulle way con SAC scale
inferiore a T4 da tempo, principalmente per l'abbondanza di nomi inutili
("da qui a lì", "scorciatoia", "continua", "sterrato ciclabile",
"collegamento con..." ecc.) che fanno casino e basta.

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

Re: [Talk-it] Tag wikipedia su via

[Jo]

ho creato un novo item in Wikidata, poi ho cambiato la referenza in OSM.

Polyglot (Sorry for my poor Italian)

2017-10-11 22:34 GMT+02:00 totera :

> Daniele Santini wrote
> > Nella mia città un utente ha aggiunto nel tag Wikipedia di una strada la
> > pagina wikipedia dedicata al personaggio a cui è intitolata la via. Ma
> > questo utilizzo non è sbagliato?
> > Changeset in questione: https://www.openstreetmap.org/changeset/52825602
> > Strada: https://www.openstreetmap.org/way/120092213
>
> Oltre a sbagliare tag l'utente ha anche sbagliato personaggio.
> L'attrice su Wikipedia risulta ancora vivente; facendo una ricerca si trova
> che la Livia Venturini a cui è intitolata la via di Imola fu una
> partigiana:
> http://memoriadibologna.comune.bologna.it/venturini-livia-479607-persona
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Risposta: Bicipolitana

[Gianluca Boero]

Grazie...tengo a mente i tuoi consigli per quando sarà realizzata quella 
di Pinerolo.


Si..concordo anche io come operator inserire il comune.

Solo una domanda...il ref 3 corrisponde al terzo tratto?


Il 11/10/2017 21:18, Lorenzo Mastrogiacomi ha scritto:

Io ho mappato le linee della bicipolitana di Pesaro.
Qui c'è l'ultimo materiale rilasciato dal comune che risale purtroppo 
al 2013. Da allora diversi tratti sono stati completati:

http://www.pesaromobilita.it/index.php?id=2331


La mappatura più o meno rispecchia la situazione attuale:
https://cycling.waymarkedtrails.org/#?map=14!43.9031!12.9025 




Questo è un esempio di linea:
https://www.openstreetmap.org/relation/3467915

al momento taggata in questo modo:
type=route
route=bicycle
network=lcn
name=Baia Flaminia - Borgo Santa Maria
ref=3
operator=Bicipolitana
colour=#509F25

Sicuramente cambierei l'operator, direi "Comune di Pesaro".
Il termine "Bicipolitana" lo metterei da qualche parte, forse 
all'inizio del nome.



Lorenzo


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


--
Gianluca Boero

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

Re: [Talk-de] finde.cash! - name / operator

[Scholtes, Martin]

Ok. Da stimme ich dir zu.
Bzgl. Abkürzungen: Ja da hast du recht, aber wie soll ich den vollen Namen denn 
da unterbringen? 

-Ursprüngliche Nachricht-
Von: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] 
Gesendet: Mittwoch, 11. Oktober 2017 22:18
An: Openstreetmap allgemeines in Deutsch 
Betreff: Re: [Talk-de] finde.cash! - name / operator



sent from a phone

> On 11. Oct 2017, at 22:04, Scholtes, Martin  wrote:
> 
> von Martin Koppenhoefer angemerktem "interbank network" beschreibt ja 
> eigentlich nur das verwendete System zur Zahlung.


das bezieht sich wohl auf die kleinen Logos auf den Bankkarten (und am 
Automaten), anhand derer man erkennen kann, ob die eigene Karte am Automaten 
genutzt werden kann - innerhalb Deutschlands und wohl auch Europas weniger 
wichtig, kann das weltweit durchaus ein Thema sein.

Bitte keine Abkürzungen verwenden in den values.

Gruß,
Martin 



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

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

Re: [Talk-it] Tag wikipedia su via

[totera]

Daniele Santini wrote
> Nella mia città un utente ha aggiunto nel tag Wikipedia di una strada la
> pagina wikipedia dedicata al personaggio a cui è intitolata la via. Ma
> questo utilizzo non è sbagliato?
> Changeset in questione: https://www.openstreetmap.org/changeset/52825602
> Strada: https://www.openstreetmap.org/way/120092213

Oltre a sbagliare tag l'utente ha anche sbagliato personaggio.
L'attrice su Wikipedia risulta ancora vivente; facendo una ricerca si trova
che la Livia Venturini a cui è intitolata la via di Imola fu una partigiana:
http://memoriadibologna.comune.bologna.it/venturini-livia-479607-persona



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

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

Re: [Talk-de] finde.cash! - name / operator

[Martin Koppenhoefer]

sent from a phone

> On 11. Oct 2017, at 22:04, Scholtes, Martin  wrote:
> 
> von Martin Koppenhoefer angemerktem "interbank network" beschreibt ja 
> eigentlich nur das verwendete System zur Zahlung.


das bezieht sich wohl auf die kleinen Logos auf den Bankkarten (und am 
Automaten), anhand derer man erkennen kann, ob die eigene Karte am Automaten 
genutzt werden kann - innerhalb Deutschlands und wohl auch Europas weniger 
wichtig, kann das weltweit durchaus ein Thema sein.

Bitte keine Abkürzungen verwenden in den values.

Gruß,
Martin 



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

Re: [Talk-de] finde.cash! - name / operator

[Scholtes, Martin]

Hallo,

also für atm der Volks- und Raiffeisenbanken bin ich für folgende 
vorgehensweise:
name: leer lassen
operater: lokales Institut
network: bvr



von Martin Koppenhoefer angemerktem "interbank network" beschreibt ja 
eigentlich nur das verwendete System zur Zahlung.

Gruß Martin

-Ursprüngliche Nachricht-
Von: Nils Vierus [mailto:n...@vierus.de] 
Gesendet: Mittwoch, 11. Oktober 2017 19:30
An: Openstreetmap allgemeines in Deutsch 
Betreff: Re: [Talk-de] finde.cash! - name / operator

dann müsste [network] bei GAs den Automatenverb_u_nd enthalten, bei Banken den 
Bankenverb_a_nd (beides völlig verschiedene Dinge). Das wird sich kaum 
durchsetzen, vermute ich.

Gruß Nils

Am 11. Oktober 2017 um 10:18:55, Martin Koppenhoefer (dieterdre...@gmail.com) 
schrieb:



sent from a phone

> On 11. Oct 2017, at 09:04, Nils Vierus  wrote:
>  
> @Martin: Mit den VR Banken ist mir das noch nicht ganz transparent: benötigen 
> wir hier in einer Vorbelegung des Attributs [name] nun mehrere Bezeichnungen 
> oder genügt uns Volksbank, VR-Bank oder so ähnlich? (In [operator] wird dann 
> der konkrete lokale Institutsname eingetragen.)


evtl. macht es hier Sinn, den tag network zu verwenden für den Verband? 
https://de.m.wikipedia.org/wiki/Bundesverband_der_Deutschen_Volksbanken_und_Raiffeisenbanken


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

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

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Martin Koppenhoefer]

sent from a phone

> On 11. Oct 2017, at 16:59, Rory McCann  wrote:
> 
> No-one's said it yet, but to me, that's a con. Not everyone likes the
> share-alike requirement, and that's fine. But there are people, like me,
> who think "share-alike" is a pro.


I also like the idea of share-alike, but in reality it’s a problem because it 
prevents use of open data by other open data projects as soon as they don’t use 
the exact same license. Remember the redaction of OSM data because we changed 
from one share alike to another? Or the incompatibility of wikipedia and osm? 
If we import data it’s a pro if there are no strings attached that would 
potentially force us to remove the data and contributions built upon this data 
in case of another (not so probable) license change.

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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Alfredo Gattai]

Nelle wiki in inglese

http://wiki.openstreetmap.org/wiki/Hiking

il name e' indicato come un tag opzionale mentre risulta essere necessario
per le relazion.
Detto questo se un sentiero che fa parte di una relation e' gia' conosciuto
con un certo nome ovviamente il nome sulla way ha senso ed e' giusto che
rimanga. La mia precisazione era tesa ad evitare quello che succede a volte
dove si trova sulle way "Sentiero CAI 151" oppure "Sentiero bolli rossi"
oppure anche qualcuno che ripete il nome della relazione dentro la way dove
magari quel pezzo di sentiero e' una scalinata antica che ha un nome
proprio che nulla ha a che fare con la relazione.
Personalmene non mi piace mappare per il rendering e quindi non metto nomi
nelle way perche' sulla pagina principale di OSM non si vedono i nomi delle
relazioni, ma non sono un fondamentalista. Molto spesso trovo nomi sulle
way che mi sembrano sensati e li lascio li anche se c'e' la relation.

Mi fai qualche esempio di nome arbitrario sulle relazioni liguri? Me le sto
ripassando tutte per consolidare la Rete Escursionistica Ligure ed il
repertorio FIE e CAI prima di farlo confluire nel catasto nazionale del
CAI. Per ora al di fuori di quello che e' stato deciso con la Regione,
all'interno del catasto CAI e FIE non ho trovato molte stranezze, se mi fai
qualche esempio mi daresti una mano.

Grazie
Alfredo



2017-10-11 18:47 GMT+02:00 matteocalosi :

> Ma questa è una linea guida condivisa? Non la trovo nè in pagina CAI nè in
> IT:Hiking.
> E non è che sia completamente d'accordo.
> Mi spiego, è ovvio che non si mette come name della way quello di una
> relation a lunga percorrenza tipo alta via oppure di relation che hanno
> nomi
> arbitrari come quelli che vedo sono stati assegnati ai sentieri liguri.
> Ma quando una relation ha un nome che sarebbe in ogni caso assegnato alle
> way che la costituiscono anche se la relation non avesse nome (esempio
> http://www.caimarostica.it/778.html) non vedo perchè non si possa
> aggiungere
> alle singole way. Al massimo sarà ridondante ma non mi sembra errato, quel
> tratto di sentiero lì ha effettivamente quel nome e non è che lo perda nel
> momento in cui una sezione CAI decide che è quello ufficiale del sentiero.
> Lo so che non si mappa per il rendering ma i renderer escursionistici non
> fanno in genere vedere i nomi delle relazioni sui sentieri (anche a ragione
> perchè visivamente il risultato non sarebbe spesso piacevole/utile, vedi
> l'esempio delle relazioni liguri) quindi aggiungere il nome di un sentiero
> sulla way è di fatto l'unico modo di vederlo. Se non fosse formalmente
> errata come cosa io preferirei aggiungerlo piuttosto che perdere la
> visualizzazione del nome dei soli sentieri che lo hanno ufficializzato.
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Silnice I/10 v Praze?

[jozka]

Co tohle?

https://cs.wikipedia.org/wiki/S%C3%AD%C5%A5_pozemn%C3%ADch_komunikac%C3%AD_v_Praze

J.

__
> Od: Jan Martinec 
> Komu: talk-cz@openstreetmap.org
> Datum: 11.10.2017 17:31
> Předmět: Re: [Talk-cz] Silnice I/10 v Praze?
>
>On 10/11/2017 05:23 PM, majka wrote:
>> Koukám na stránky ŘSD ,
>> a vypadá to, že je to v OSM dobře.
>>
>> 2017-10-11 17:09 GMT+02:00 Jan Martinec > >:
>>
>> Ahoj,
>>
>> podle OSM vede Prahou silnice I/10.
>> https://www.openstreetmap.org/#map=15/50.1142/14.5698
>> 
>> Dvakrát, paralelně. Jednou od sjezdu z dálnice D10, jako Novopacká,
>> a podruhé v pokračování II/611, jako Chlumecká.
>>
>> Aby to bylo ještě veselejší, tak podle ŘSD vede I/10 pouze z Turnova
>> do Polska, a v Praze ji neeviduje vůbec.
>>
>> Máme nějaký autoritativní zdroj, nebo je to obojí blud a patří ten
>> ref smazat? Podle Mapillary to jako I/10 značený taky není...
>>
>> Zdar,
>> Honza "Piškvor" Martinec
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> 
>>
>>
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>Aha, to vypadá autoritativně sdostatek.
>
>Koukám, že v týhle mapě je to značený jako "10" a "10M" - zkusím to 
>dohledat z nějakýho licenčně kompatibilního zdroje, nebo to holt odložím 
>na pozdější terénní průzkum.
>
>Díky,
>HPM
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>
>

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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Alfredo Gattai]

In realta' l'operator per lo meno nel nostro paese e secondo le varie leggi
regionali e' quello che si occupa sia della manutenzione che della
segnaletica del percorso. Di fatto ne ha la responsabilita'. Tale Ente poi
puo' anche dare la manutenzione della segnaletica ed anche qualche lavoro
di manutenzione ordinaria in convenzione ad associazioni come il CAI o in
appalto a ditte e cooperative.
L'importante e' metterlo solo se si e' sicuri.
In nessuna wiki si trova come tag delle singole way comunque.


2017-10-11 10:29 GMT+02:00 Cascafico Giovanni :

> IMHO l'operatore (quello che una volta in montagna si chiamava "lo
> stradino") che sistema fisicamente il sentiero/strada può essere un
> tag delle way. E può anche convivere con l'operatore delle relation
> che invece si occupa della segnaletica, ovvero dell'aspetto non fisico
> dell'elemento.
>
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Risposta: Bicipolitana

[Lorenzo Mastrogiacomi]

Io ho mappato le linee della bicipolitana di Pesaro.
Qui c'è l'ultimo materiale rilasciato dal comune che risale purtroppo
al 2013. Da allora diversi tratti sono stati completati:
http://www.pesaromobilita.it/index.php?id=2331


La mappatura più o meno rispecchia la situazione attuale:
https://cycling.waymarkedtrails.org/#?map=14!43.9031!12.9025


Questo è un esempio di linea:
https://www.openstreetmap.org/relation/3467915

al momento taggata in questo modo:
type=route
route=bicycle
network=lcn
name=Baia Flaminia - Borgo Santa Maria
ref=3
operator=Bicipolitana
colour=#509F25

Sicuramente cambierei l'operator, direi "Comune di Pesaro".
Il termine "Bicipolitana" lo metterei da qualche parte, forse
all'inizio del nome.


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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Martin Koppenhoefer]

sent from a phone

> On 11. Oct 2017, at 18:47, matteocalosi  wrote:
> 
> Ma quando una relation ha un nome che sarebbe in ogni caso assegnato alle
> way che la costituiscono anche se la relation non avesse nome (esempio
> http://www.caimarostica.it/778.html) non vedo perchè non si possa aggiungere
> alle singole way. Al massimo sarà ridondante ma non mi sembra errato, quel
> tratto di sentiero lì ha effettivamente quel nome e non è che lo perda nel
> momento in cui una sezione CAI decide che è quello ufficiale del sentiero. 
> Lo so che non si mappa per il rendering ma i renderer escursionistici non
> fanno in genere vedere i nomi delle relazioni sui sentieri (anche a ragione
> perchè visivamente il risultato non sarebbe spesso piacevole/utile, vedi
> l'esempio delle relazioni liguri) quindi aggiungere il nome di un sentiero
> sulla way è di fatto l'unico modo di vederlo. 


+1

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

Re: [Talk-de] finde.cash! - name / operator

[Martin Koppenhoefer]

sent from a phone

> On 11. Oct 2017, at 19:30, Nils Vierus  wrote:
> 
> dann müsste [network] bei GAs den Automatenverb_u_nd enthalten, bei Banken 
> den Bankenverb_a_nd (beides völlig verschiedene Dinge). Das wird sich kaum 
> durchsetzen, vermute ich.


für Bankautomaten gibt es hier eine Zusammenstellung: 
https://en.m.wikipedia.org/wiki/Interbank_network

Gruß,
Martin 

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

Re: [OSM-co] Abreviaturas - Consenso

[Fredy Rivera]

2017-10-11 12:18 GMT-05:00 Jorge Aguirre :

> Para terminar con este tema, quisiera pedir a la Comunidad de Talk-Co
> emitan su última palabra al respecto y podamos todos proceder de acuerdo a
> el consenso común:
>
>
> En su última respuesta, me baso en lo sugerido por *Andrés Gomez Casanova*
> - *"Por todo lo anterior, no considero apropiado ese cambio, y lo que si
> deberíamos hacer es poner los nombres completos de lo que esté en
> abreviatura. También se debería eliminar cualquier tag de Addr ya que eso
> corresponde a direcciones y no a calles.”*
>
>
> Con esta aunado a todas las anteriores respuestas, creo es seguro decir
> que todos *acordamos* con que la utilización de los nombres de las calles
> en su *forma abreviada NO DEBE SER UTILIZADO para nombrar las calles*,
> aunque así aparezcan físicamente en los rótulos de las mismas.
>
> Además, en los casos en los que ya se encuentre el nombre abreviado dentro
> de la casilla *addr:street*, todos deberán eliminarse debido a que ésta
> corresponde específicamente a las direcciones y no a los nombres de las
> calles.
>
> ¿Estamos todos de acuerdo con esto?
>
> Y muchas gracias a todos por aclararme este punto!
>
Si Jorge, estamos de acuerdo con ese punto, procedamos de esa manera.

 No veo objeciones en el horizontes, si hay alguna objeción por favor
contestar el día de hoy, sino queda en firme y será documentada en la wiki.

salu2
Fredy Rivera


>
> Jorge Aguirre
> Geographer
> Kaart Group, LLC
> jo...@kaartgroup.com
> +(502) 4191 1999 
> www.kaartgroup.com
>
>
>
> *“Let's make our planet great again.”*
> - Emmanuel Macron
>   President of France
>
>
>
> 2017-10-10 23:09 GMT-06:00 :
>
>> Envíe los mensajes para la lista Talk-co a
>> talk-co@openstreetmap.org
>>
>> Para subscribirse o anular su subscripción a través de la WEB
>> https://lists.openstreetmap.org/listinfo/talk-co
>>
>> O por correo electrónico, enviando un mensaje con el texto "help" en
>> el asunto (subject) o en el cuerpo a:
>> talk-co-requ...@openstreetmap.org
>>
>> Puede contactar con el responsable de la lista escribiendo a:
>> talk-co-ow...@openstreetmap.org
>>
>> Si responde a algún contenido de este mensaje, por favor, edite la
>> linea del asunto (subject) para que el texto sea mas especifico que:
>> "Re: Contents of Talk-co digest...". Además, por favor, incluya en la
>> respuesta sólo aquellas partes del mensaje a las que está
>> respondiendo.
>>
>>
>> Asuntos del día:
>>
>>1. Re: Resumen de Talk-co, Vol 111, Envío 2 (Andres Gomez Casanova)
>>
>>
>> --
>>
>> Message: 1
>> Date: Wed, 11 Oct 2017 00:08:14 -0500
>> From: Andres Gomez Casanova 
>> To: OpenStreetMap Colombia 
>> Subject: Re: [OSM-co] Resumen de Talk-co, Vol 111, Envío 2
>> Message-ID: 
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hola de nuevo Jorge
>>
>> En general las abreviaciones no son buenas a nivel de datos / bases de
>> datos. Teniendo presente que OpenStreetMap es un gran conjunto de datos,
>> estos deben ser los más puros y simples posibles.
>>
>> Revisando el Wiki, en general no se recomiendan las abreviaciones, ya que
>> esta operación puede ser realizada por una máquina. Un algoritmo puede
>> convertir Carrera a Kr, Calle a Cl, Avenida a Av, fácilmente.
>> Además, escribir Carrera en un campo y Kr en otro, es en cierta forma
>> redundancia de datos, y no está ofreciendo más información, sino diferentes
>> formas de escribir lo mismo.
>> Con respecto a eso la sección Names del Wiki indica que no se debe usar
>> abreviaciones: https://wiki.openstreetmap.org
>> /wiki/Names#Abbreviation_.28don.27t_do_it.29 <
>> https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28d
>> on.27t_do_it.29>
>>
>> Si el sistema de abreviaciones es para un mecanismo como Nominatim, este
>> tiene unas tablas de correspondencia entre las posibles abreviaturas y sus
>> valores. Aquí se ven algunas de estas tablas:https://wiki.openstreet
>> map.org/wiki/Name_finder:Abbreviations > g/wiki/Name_finder:Abbreviations>
>> Si vas a crear un sistema que use los datos de OSM, entonces debes tener
>> algo similar, en vez de introducir más datos.
>>
>> Viendo un hilo de discusión de OSM en GitHub, veo que lonvia escribe lo
>> siguiente sobre short_name:
>> short_name should be a recognizable, commonly used short version of the
>> name, not a nick name (use alt_name for that) and not an abbreviation
>> (might go into ref, although that's a stretch, too) and it should certainly
>> be correct
>> Ahí se indica que ese tag no debe ser usado para abreviaciones.
>>
>> Finalmente, si se considerara aceptar esa abreviación, sería necesario
>> cambiar muchos datos en OSM. Algunos casos puede llegar a entrar en
>> colisión frente a algún uso 

Re: [Talk-it] tabelle accesso su ciclabili e ciclopedonali

[Volker Schmidt]

Secondo l'esperto Enrico Chiarini della FIAB (che ho contatto
appositamente) l'affermazione del ciclistaurbano che le ciclopedonali in
Italia hanno l'obbligo di uso per ciclisti è falsa.

On 11 October 2017 at 10:03, emmexx  wrote:

> Segnalo questa pagina che chiarisce tutti i punti oscuri evidenziati da
> Martin:
>
> http://www.ciclistaurbano.net/problemi_obbligo_tutti_ciclisti_usare_piste_
> ciclabili_art_182_codice_strada.html
>
> ciao
> maxx
>
> ___
> 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] Disconnected addresses

[Martijn van Exel]

Hi all,

Matthew Darwin pointed out on Github that some street name updates by the
Telenav team lead to 'orphaned' address nodes. The ticket is here:
https://github.com/TelenavMapping/mapping-projects/issues/34

This is just to let you know that we are aware and planning to fix soonest.

Thanks and my apologies. Let us know if you encountered this anywhere else.

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

Re: [Talk-GB] Barriers and PRoWs

[Roland Olbricht]

Hi all,


I should be most grateful for assistance in achieving the following

> 3. to obtain such results for an individual civil parish, either by
> selecting those ways within an admin level 10 boundary named
> "Checkendon", say, or selecting those PRoWs whose prow_ref value
> contains "Checkendon"

For the sake of simplicity, all the follwoing examples are based on the 
area spanned by teh object tagged with name="Checkendon" and 
admin_levlel=10. Feel free to play with the values - what the link 
points at is not changed by editing the query.



1. to identify PRoWs having stiles


https://overpass-turbo.eu/s/sh7


2. to invert and obtain PRoWs not having stiles


https://overpass-turbo.eu/s/sh8


4. to be able to export such results to a tabular form


I'm not sure which columns such a table should have. I have made an 
example where way id, value of prow_ref, and if barriers are present are 
columns:

https://overpass-turbo.eu/s/sh9

Best regards,

Roland

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

Re: [diversity-talk] Survey by Geochicas

[code elusive]

hello Clifford :)

I was not involved in the creation of this survey, but I will relay the
message :)


~elusive


On 10/11/2017 08:25 PM, Clifford Snow wrote:
> Is it possible for you to also translate the blog post in to the langues
> offered by the survey?
> 
> Thanks in advance,
> Clifford
> 
> On Wed, Oct 11, 2017 at 9:35 AM, code elusive  > wrote:
> 
> 
> hello :)
> 
> Geochicas launched a survey today "in order to make an analysis on the
> role, representation and participation of women in OSM"
> 
> You can find it at
> 
> http://geochicas.org/index.php/que-hacemos/proyectos/encuesta-sobre-genero/
> 
> 
> 
> The survey is translated into 6 languages:
> Español, English, Française, Deutsche, Português and Shqip
> 
> ..and they mention they are welcoming comments on different social
> networks through the hashtags #Geochicas #OSMintegra #OSMintegrates
> 
> 
> ~ elusive
> 
> 
> ___
> diversity-talk mailing list
> diversity-talk@openstreetmap.org
> 
> https://lists.openstreetmap.org/listinfo/diversity-talk
> 
> 
> 
> 
> 
> -- 
> @osm_seattle
> osm_seattle.snowandsnow.us 
> OpenStreetMap: Maps with a human touch




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

Re: [Talk-de] finde.cash! - name / operator

[Nils Vierus]

dann müsste [network] bei GAs den Automatenverb_u_nd enthalten, bei Banken den 
Bankenverb_a_nd (beides völlig verschiedene Dinge). Das wird sich kaum 
durchsetzen, vermute ich.

Gruß Nils

Am 11. Oktober 2017 um 10:18:55, Martin Koppenhoefer (dieterdre...@gmail.com) 
schrieb:



sent from a phone

> On 11. Oct 2017, at 09:04, Nils Vierus  wrote:
>  
> @Martin: Mit den VR Banken ist mir das noch nicht ganz transparent: benötigen 
> wir hier in einer Vorbelegung des Attributs [name] nun mehrere Bezeichnungen 
> oder genügt uns Volksbank, VR-Bank oder so ähnlich? (In [operator] wird dann 
> der konkrete lokale Institutsname eingetragen.)


evtl. macht es hier Sinn, den tag network zu verwenden für den Verband? 
https://de.m.wikipedia.org/wiki/Bundesverband_der_Deutschen_Volksbanken_und_Raiffeisenbanken


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

Re: [OSM-co] Abreviaturas - Consenso

[Jorge Aguirre]

Para terminar con este tema, quisiera pedir a la Comunidad de Talk-Co
emitan su última palabra al respecto y podamos todos proceder de acuerdo a
el consenso común:


En su última respuesta, me baso en lo sugerido por *Andrés Gomez Casanova*
- *"Por todo lo anterior, no considero apropiado ese cambio, y lo que si
deberíamos hacer es poner los nombres completos de lo que esté en
abreviatura. También se debería eliminar cualquier tag de Addr ya que eso
corresponde a direcciones y no a calles.”*


Con esta aunado a todas las anteriores respuestas, creo es seguro decir que
todos *acordamos* con que la utilización de los nombres de las calles
en su *forma
abreviada NO DEBE SER UTILIZADO para nombrar las calles*, aunque así
aparezcan físicamente en los rótulos de las mismas.

Además, en los casos en los que ya se encuentre el nombre abreviado dentro
de la casilla *addr:street*, todos deberán eliminarse debido a que ésta
corresponde específicamente a las direcciones y no a los nombres de las
calles.

¿Estamos todos de acuerdo con esto?

Y muchas gracias a todos por aclararme este punto!


Jorge Aguirre
Geographer
Kaart Group, LLC
jo...@kaartgroup.com
+(502) 4191 1999 
www.kaartgroup.com



*“Let's make our planet great again.”*
- Emmanuel Macron
  President of France



2017-10-10 23:09 GMT-06:00 :

> Envíe los mensajes para la lista Talk-co a
> talk-co@openstreetmap.org
>
> Para subscribirse o anular su subscripción a través de la WEB
> https://lists.openstreetmap.org/listinfo/talk-co
>
> O por correo electrónico, enviando un mensaje con el texto "help" en
> el asunto (subject) o en el cuerpo a:
> talk-co-requ...@openstreetmap.org
>
> Puede contactar con el responsable de la lista escribiendo a:
> talk-co-ow...@openstreetmap.org
>
> Si responde a algún contenido de este mensaje, por favor, edite la
> linea del asunto (subject) para que el texto sea mas especifico que:
> "Re: Contents of Talk-co digest...". Además, por favor, incluya en la
> respuesta sólo aquellas partes del mensaje a las que está
> respondiendo.
>
>
> Asuntos del día:
>
>1. Re: Resumen de Talk-co, Vol 111, Envío 2 (Andres Gomez Casanova)
>
>
> --
>
> Message: 1
> Date: Wed, 11 Oct 2017 00:08:14 -0500
> From: Andres Gomez Casanova 
> To: OpenStreetMap Colombia 
> Subject: Re: [OSM-co] Resumen de Talk-co, Vol 111, Envío 2
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> Hola de nuevo Jorge
>
> En general las abreviaciones no son buenas a nivel de datos / bases de
> datos. Teniendo presente que OpenStreetMap es un gran conjunto de datos,
> estos deben ser los más puros y simples posibles.
>
> Revisando el Wiki, en general no se recomiendan las abreviaciones, ya que
> esta operación puede ser realizada por una máquina. Un algoritmo puede
> convertir Carrera a Kr, Calle a Cl, Avenida a Av, fácilmente.
> Además, escribir Carrera en un campo y Kr en otro, es en cierta forma
> redundancia de datos, y no está ofreciendo más información, sino diferentes
> formas de escribir lo mismo.
> Con respecto a eso la sección Names del Wiki indica que no se debe usar
> abreviaciones: https://wiki.openstreetmap.org
> /wiki/Names#Abbreviation_.28don.27t_do_it.29 <
> https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
> >
>
> Si el sistema de abreviaciones es para un mecanismo como Nominatim, este
> tiene unas tablas de correspondencia entre las posibles abreviaturas y sus
> valores. Aquí se ven algunas de estas tablas:https://wiki.openstreet
> map.org/wiki/Name_finder:Abbreviations  g/wiki/Name_finder:Abbreviations>
> Si vas a crear un sistema que use los datos de OSM, entonces debes tener
> algo similar, en vez de introducir más datos.
>
> Viendo un hilo de discusión de OSM en GitHub, veo que lonvia escribe lo
> siguiente sobre short_name:
> short_name should be a recognizable, commonly used short version of the
> name, not a nick name (use alt_name for that) and not an abbreviation
> (might go into ref, although that's a stretch, too) and it should certainly
> be correct
> Ahí se indica que ese tag no debe ser usado para abreviaciones.
>
> Finalmente, si se considerara aceptar esa abreviación, sería necesario
> cambiar muchos datos en OSM. Algunos casos puede llegar a entrar en
> colisión frente a algún uso que le hayan dado ya a short_name y sería aún
> más complicado. También hay que decir que no es intuitivo poner el nombre
> corto como abreviatura, por lo que las nuevas calles mapeadas tampoco
> tendrían el estándar.
>
> Por ejemplo, para mi la Carrera 30 (name) es el nombre normal, el oficial
> es Avenida Quito (oficial_name) y el corto es la NQS (short_name)
> Tomando Carrera 30 se puede convertir a KR 30 fácilmente, sin tener que
> dejar 

Re: [diversity-talk] Survey by Geochicas

[code elusive]

Please note that the survey asks some personal questions
and all answers (and metadata such as IP addresses)
are saved (forever) on the Google servers.

~elusive



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

Re: [Talk-it] Fire hydrant voting

[Martin Koppenhoefer]

2017-10-11 16:01 GMT+02:00 paolo bubici :

> Martin,
> quindi potrebbe essere prematura metterla ai voti? Ci bruciamo anche gli
> attacchi di mandata :-) 
>
> Bubix
>


non lo so ;-)
Potrebbe essere indicato di mandare prima un RFC (non ricordo se è già
stato fatto) per sentire evventuali argomenti e preoccupazioni, ma non lo
vedo problematico, perché non sostituisce niente, è un nuovo tag.

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

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

Re-visiting this changeset I see that of the 620 ways with tag 
"source:name"="geobase.ca", 552 ways have no name restored. See for example way 
32798176 where I validated the name + added source:name Overpass query 
http://overpass-turbo.eu/s/sh6

Pierre 
 

Le mercredi 11 octobre 2017 11:26:35 HAE, Frederik Ramm 
 a écrit :  
 
 Hi,

On 10.10.2017 03:16, Frederik Ramm wrote:
> I still have the raw data and I'll write a quick script
> that finds these cases and restores the names.

Should be done here

https://www.openstreetmap.org/changeset/52829433

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[matteocalosi]

Ma questa è una linea guida condivisa? Non la trovo nè in pagina CAI nè in
IT:Hiking.
E non è che sia completamente d'accordo. 
Mi spiego, è ovvio che non si mette come name della way quello di una
relation a lunga percorrenza tipo alta via oppure di relation che hanno nomi
arbitrari come quelli che vedo sono stati assegnati ai sentieri liguri. 
Ma quando una relation ha un nome che sarebbe in ogni caso assegnato alle
way che la costituiscono anche se la relation non avesse nome (esempio
http://www.caimarostica.it/778.html) non vedo perchè non si possa aggiungere
alle singole way. Al massimo sarà ridondante ma non mi sembra errato, quel
tratto di sentiero lì ha effettivamente quel nome e non è che lo perda nel
momento in cui una sezione CAI decide che è quello ufficiale del sentiero. 
Lo so che non si mappa per il rendering ma i renderer escursionistici non
fanno in genere vedere i nomi delle relazioni sui sentieri (anche a ragione
perchè visivamente il risultato non sarebbe spesso piacevole/utile, vedi
l'esempio delle relazioni liguri) quindi aggiungere il nome di un sentiero
sulla way è di fatto l'unico modo di vederlo. Se non fosse formalmente
errata come cosa io preferirei aggiungerlo piuttosto che perdere la
visualizzazione del nome dei soli sentieri che lo hanno ufficializzato.



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

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

[diversity-talk] Survey by Geochicas

[code elusive]

hello :)

Geochicas launched a survey today "in order to make an analysis on the
role, representation and participation of women in OSM"

You can find it at
http://geochicas.org/index.php/que-hacemos/proyectos/encuesta-sobre-genero/

The survey is translated into 6 languages:
Español, English, Française, Deutsche, Português and Shqip

..and they mention they are welcoming comments on different social
networks through the hashtags #Geochicas #OSMintegra #OSMintegrates


~ elusive



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

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Pierre Béland]

Great, thanks Frederik.
 
Pierre 
 

Le mercredi 11 octobre 2017 11:26:35 HAE, Frederik Ramm 
 a écrit :  
 
 Hi,

On 10.10.2017 03:16, Frederik Ramm wrote:
> I still have the raw data and I'll write a quick script
> that finds these cases and restores the names.

Should be done here

https://www.openstreetmap.org/changeset/52829433

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[Joe Sapletal]

This is really cool.  Can I suggest for the Twin Cities metro area someone 
doing something similar with the Metro Regional Centerlines Collaborative Local 
Centerlines (MRCC)?  I know that Dakota County hasn’t submitted centerlines to 
Tiger in a couple of years, but will be for the next update.  Not sure about 
the other counties though.  There very well may be areas that the MRCC will be 
a better source than the Tiger data.

https://gisdata.mn.gov/dataset/us-mn-state-metrogis-trans-mrcc-centerlines

Joe

From: Ian Dees
Sent: Wednesday, October 11, 2017 10:25 AM
To: Badita Florin
Cc: talk-us@openstreetmap.org Openstreetmap
Subject: Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

It would be interesting to see what differences CYGNUS would turn up. What 
would the output of CYGNUS be?

I put together the TIGER 2017 layer that's in the editors right now. I'll work 
on writing up how I did it later today.

Basically: I used tiger-tiles (https://github.com/iandees/tiger-tiles) to 
generate a vector tiles database with expanded road names from TIGER 2017. Then 
I downloaded an osm-qa-tiles (https://osmlab.github.io/osm-qa-tiles/) file for 
the United States and ran osmlint's tigerDelta 
(https://github.com/osmlab/osmlint/tree/master/validators/tigerDelta) to find 
the segments that had different geometry. The output was then ran through 
Tippecanoe to generate a vector tileset and posted to Mapbox as the low zoom 
red features.

On Wed, Oct 11, 2017 at 4:03 AM, Badita Florin  wrote:
Hi, i wanted to ask if there will be interest around comparing TIGER 2017 with 
what we have in OSM, using CYGNUS, in a automated way. 
http://www.openstreetmap.org/user/mvexel/diary/36746
 
On top of cygnus, i have developed shgp2cygnus, were you can place any 
shapefile, any size, you provide a translation file, and, in the end, you get a 
list with all the ways that are in the TIGER dataset, but not in OSM.
This would be something useful for the community ? 
 
I don`t know if somebody is already doing something similar, or what is the 
status ? Were can i read more ?
I knoiw that the TIGER 2017 Overlay in JOSM shows in red the roads that are not 
in OSM, but are in TIger 2017. 
But I don`t know were to read more, and if the data is accessible to download 
directly, not just show as a WMS Layer.
 
It will take around 7-14 days to process all USA”

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


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

Re: [Talk-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[mbranco]

Mea culpa (parziale) : ero convinto che "stream" significasse torrente.
Ora ho consultato un po' di dizionari online, per "stream" trovo un po' di
tutto (da corso d'acqua a ruscello a fiume), però la traduzione più diffusa
per torrente è "torrent".

Il criterio di provare a saltare un corso d'acqua per classificarlo river o
stream lo trovo ridicolo (e lo cancellerei dalla wiki), ma in effetti
proverei a saltare un ruscello, non un torrente!

Quindi sono d'accordo a usare "river" sia per i fiumi che per i torrenti,
c'è però da cambiare la pagina principale della wiki italiana [1] che invece
dice di usare "stream" per i torrenti (era questo che mi aveva ingannato).

Sul nome mi rimangono i dubbi: capisco il ragionamento di Max, anche se non
si dovrebbe mappare per il rendering... 

@Martin:
bella l'idea di waterway:it=torrente, la userò! (per es. in Val d'Aosta c'è
un solo "fiume", la Dora Baltea, e da tutte le valli laterali scendono dei
"torrenti": vorrei averla una distinzione)

[1] http://wiki.openstreetmap.org/wiki/IT:Map_Features



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

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

Re: [Talk-cz] Silnice I/10 v Praze?

[Jan Martinec]

On 10/11/2017 05:23 PM, majka wrote:

Koukám na stránky ŘSD ,
a vypadá to, že je to v OSM dobře.

2017-10-11 17:09 GMT+02:00 Jan Martinec >:

Ahoj,

podle OSM vede Prahou silnice I/10.
https://www.openstreetmap.org/#map=15/50.1142/14.5698

Dvakrát, paralelně. Jednou od sjezdu z dálnice D10, jako Novopacká,
a podruhé v pokračování II/611, jako Chlumecká.

Aby to bylo ještě veselejší, tak podle ŘSD vede I/10 pouze z Turnova
do Polska, a v Praze ji neeviduje vůbec.

Máme nějaký autoritativní zdroj, nebo je to obojí blud a patří ten
ref smazat? Podle Mapillary to jako I/10 značený taky není...

Zdar,
Honza "Piškvor" Martinec

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





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



Aha, to vypadá autoritativně sdostatek.

Koukám, že v týhle mapě je to značený jako "10" a "10M" - zkusím to 
dohledat z nějakýho licenčně kompatibilního zdroje, nebo to holt odložím 
na pozdější terénní průzkum.


Díky,
HPM

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

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Frederik Ramm]

Hi,

On 10.10.2017 03:16, Frederik Ramm wrote:
> I still have the raw data and I'll write a quick script
> that finds these cases and restores the names.

Should be done here

https://www.openstreetmap.org/changeset/52829433

Bye
Frederik

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

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

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automated way.

[Ian Dees]

It would be interesting to see what differences CYGNUS would turn up. What
would the output of CYGNUS be?

I put together the TIGER 2017 layer that's in the editors right now. I'll
work on writing up how I did it later today.

Basically: I used tiger-tiles (https://github.com/iandees/tiger-tiles) to
generate a vector tiles database with expanded road names from TIGER 2017.
Then I downloaded an osm-qa-tiles (https://osmlab.github.io/osm-qa-tiles/)
file for the United States and ran osmlint's tigerDelta (
https://github.com/osmlab/osmlint/tree/master/validators/tigerDelta) to
find the segments that had different geometry. The output was then ran
through Tippecanoe to generate a vector tileset and posted to Mapbox as the
low zoom red features.

On Wed, Oct 11, 2017 at 4:03 AM, Badita Florin 
wrote:

> Hi, i wanted to ask if there will be interest around comparing TIGER 2017
> with what we have in OSM, using CYGNUS, in a automated way.
> http://www.openstreetmap.org/user/mvexel/diary/36746
>
>
>
> On top of cygnus, i have developed shgp2cygnus, were you can place any
> shapefile, any size, you provide a translation file, and, in the end, you
> get a list with all the ways that are in the TIGER dataset, but not in OSM.
>
> This would be something useful for the community ?
>
>
>
> I don`t know if somebody is already doing something similar, or what is
> the status ? Were can i read more ?
>
> I knoiw that the TIGER 2017 Overlay in JOSM shows in red the roads that
> are not in OSM, but are in TIger 2017.
>
> But I don`t know were to read more, and if the data is accessible to
> download directly, not just show as a WMS Layer.
>
>
>
> It will take around 7-14 days to process all USA”
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-cz] Silnice I/10 v Praze?

[majka]

Koukám na stránky ŘSD , a
vypadá to, že je to v OSM dobře.

2017-10-11 17:09 GMT+02:00 Jan Martinec :

> Ahoj,
>
> podle OSM vede Prahou silnice I/10.
> https://www.openstreetmap.org/#map=15/50.1142/14.5698
> Dvakrát, paralelně. Jednou od sjezdu z dálnice D10, jako Novopacká, a
> podruhé v pokračování II/611, jako Chlumecká.
>
> Aby to bylo ještě veselejší, tak podle ŘSD vede I/10 pouze z Turnova do
> Polska, a v Praze ji neeviduje vůbec.
>
> Máme nějaký autoritativní zdroj, nebo je to obojí blud a patří ten ref
> smazat? Podle Mapillary to jako I/10 značený taky není...
>
> Zdar,
> Honza "Piškvor" Martinec
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] Tag wikipedia su via

[Jo]

lo ho cambiato

https://www.openstreetmap.org/changeset/52829029#map=16/44.3515/11.7058=N

Polyglot

2017-10-11 17:04 GMT+02:00 Andrea Musuruane :

> Ciao,
>
> 2017-10-11 16:54 GMT+02:00 Daniele Santini :
>
>> Nella mia città un utente ha aggiunto nel tag Wikipedia di una strada la
>> pagina wikipedia dedicata al personaggio a cui è intitolata la via. Ma
>> questo utilizzo non è sbagliato?
>> Changeset in questione: https://www.openstreetmap.org/changeset/52825602
>> Strada: https://www.openstreetmap.org/way/120092213
>>
>
> Secondo me è decisamente sbagliato.
>
> Ciao,
>
> Andrea
>
>
> ___
> 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-cz] Silnice I/10 v Praze?

[Jan Martinec]

Ahoj,

podle OSM vede Prahou silnice I/10.
https://www.openstreetmap.org/#map=15/50.1142/14.5698
Dvakrát, paralelně. Jednou od sjezdu z dálnice D10, jako Novopacká, a 
podruhé v pokračování II/611, jako Chlumecká.


Aby to bylo ještě veselejší, tak podle ŘSD vede I/10 pouze z Turnova do 
Polska, a v Praze ji neeviduje vůbec.


Máme nějaký autoritativní zdroj, nebo je to obojí blud a patří ten ref 
smazat? Podle Mapillary to jako I/10 značený taky není...


Zdar,
Honza "Piškvor" Martinec

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

Re: [Talk-it] Tag wikipedia su via

[Andrea Musuruane]

Ciao,

2017-10-11 16:54 GMT+02:00 Daniele Santini :

> Nella mia città un utente ha aggiunto nel tag Wikipedia di una strada la
> pagina wikipedia dedicata al personaggio a cui è intitolata la via. Ma
> questo utilizzo non è sbagliato?
> Changeset in questione: https://www.openstreetmap.org/changeset/52825602
> Strada: https://www.openstreetmap.org/way/120092213
>

Secondo me è decisamente sbagliato.

Ciao,

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

Re: [Talk-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[Max1234Ita]

Personalmente, se trovo dei fossi o ruscelli taggati come "river", li
correggo, però sono d'accordo nel mantenere la dicitura "Fiume" o "Torrente"
nel nome.
Forse non avrò un pensiero "database-oriented" ma trovo che sia d'aiuto per
chi la mappa la usa, la esplora e vi ricerca informazioni.

Se io, utente della domenica, sulla mappa trovo un corso d'acqua e vedo
scritto solo il nome, mi tocca affidarmi al rendering per capire di cosa si
tratta, con conseguente sforzo intellettuale e fisico (osservare il colore e
lo stile del disegno; a volte su un display piccolo non è così facile); se
invece è la Mappa stessa ad aiutarmi dicendomi "Torrente Quelchelè", ho
l'informazione subito...

Poi, se ci sono anche tutti gli altri tag che forse sono ben più utili alle
applicazioni ed ai loro  programmatori, ben venga.

Max




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

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

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Rory McCann]

Hi all,

On 11/10/17 15:02, Martin Koppenhoefer wrote:

For me, criterions pro wikidata are:
- it has a very permissive license (cc0)


No-one's said it yet, but to me, that's a con. Not everyone likes the
share-alike requirement, and that's fine. But there are people, like me,
who think "share-alike" is a pro. I don't really like some corporation
using data I created without having to give it back.

This sort of thing has been argued since the start of (internet) time,
with the "BSD is more free! No GPL is more free!".


--

Rory
who yes, would probably be considered a long haired hippie commie pinko 
socialist by some. ;)


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

Re: [Talk-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[liste DOT girarsi AT posteo DOT eu]

Il 11/10/2017 11:37, mbranco ha scritto:

Domanda banale, ma non trovo discussioni precedenti a riguardo:
vedo che parecchi corsi d'acqua hanno il name che inizia con "Fiume" o
"Torrente", e parecchi altri no;
per es. il Po si chiama solo "Po", il Piave si chiama "Fiume Piave".

L'altra cosa che ho notato è che in Italia ci sono moltissimi fiumi
(waterway=river): è vero che c'è ambiguità tra stream e river, però almeno
nei casi dove il name="Torrente ..." , mi sembrerebbe giusto mettere
waterway=stream (oltre che toghliere dal nome "Torrente").

Cosa ne pensate?

Un saluto,
Marco

P.S. Veramente la wiki per waterway=river cita come esempi di name "River
Nile" e "River Thames", ma non mi convince... In wikipedia per es. vedo che
solo i laghi hanno nome che inizia con "Lago ..." , i fiumi non hanno
"Fiume" come inizio del nome.



Adesso sono in crisi, se stream e river, sono differenti solo per 
larghezza, tra me ed uno che fa salti in lungo, c'è un problema di distanza.


Praticamente devo rifare tutta l'idrografia della mia zona, andando sul 
posto, valutare la larghezza in fondovalle, poi a metà montagna, ed 
infine alla sorgente, per cui, se ragiono così, ho diversi tratti di 
stream che poi diventano river.



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

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

[Talk-it] Tag wikipedia su via

[Daniele Santini]

Nella mia città un utente ha aggiunto nel tag Wikipedia di una strada la
pagina wikipedia dedicata al personaggio a cui è intitolata la via. Ma
questo utilizzo non è sbagliato?
Changeset in questione: https://www.openstreetmap.org/changeset/52825602
Strada: https://www.openstreetmap.org/way/120092213
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] Aperçu statistique des contributeurs OSM - Le pouls des contributeurs

[Pierre Béland]

Je viens de publier un journal OSM (en anglais) où j'analyse les contributeus 
OSM, en essayant d'avoir une perspective différente sur leurs contributions, et 
s'éloigner des gros nombres qui montrent des millions de contributeurs. 
Je montre brièvement les résultats d'une analyse de cohorte des contributeurs 
OSM. Ces analyses sont souvent utilisées pour comparer la progression de 
différents groupes à partir du premier jour d'un événement particulier et 
analyser leur comportement pendant une certaine période. Ils aident à révéler 
les tendances dans les données. Pour OSM, cela permet d'observer le grand pic 
de nouvelles entrées qui est suivi par des départs massifs le mois prochain. En 
fait, la majorité des contributeurs ne participent pas plus d'une journée.  Ce 
phénomène Coup de coeur est ce que j'appelle le «Pouls des contributeurs OSM».  
Il ne faut pas confondre ces brèves Visites de découverte (quelques données 
ajoutées) avec les contributions plus permanentes.
Je passe également en revue les statistiques mensuelles des contributeurs et 
des contributions les «colorant» avec le profil des contributeurs selon le 
nombre cumulé de jours d'édition. Cela permet de montrerl'hétérogénéité entre 
la très grande majorité des contributeurs qui contribuent de manière minimale 
et à l'autre extrême de la courbe de distribution, la minorité qui contribue 
massivement à OSM.
Article de Blog https://www.openstreetmap.org/user/PierZen/diary/42470Twitter 
https://twitter.com/pierzen/status/917956483169619968 
Pierre 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-us] Comparing Tiger 2017 dataset with OSM in a automated way.

[Badita Florin]

Hi, i wanted to ask if there will be interest around comparing TIGER 2017
with what we have in OSM, using CYGNUS, in a automated way.
http://www.openstreetmap.org/user/mvexel/diary/36746



On top of cygnus, i have developed shgp2cygnus, were you can place any
shapefile, any size, you provide a translation file, and, in the end, you
get a list with all the ways that are in the TIGER dataset, but not in OSM.

This would be something useful for the community ?



I don`t know if somebody is already doing something similar, or what is the
status ? Were can i read more ?

I knoiw that the TIGER 2017 Overlay in JOSM shows in red the roads that are
not in OSM, but are in TIger 2017.

But I don`t know were to read more, and if the data is accessible to
download directly, not just show as a WMS Layer.



It will take around 7-14 days to process all USA”
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Christoph Hormann]

On Wednesday 11 October 2017, Martin Koppenhoefer wrote:
> From what I have seen so far, this should probably be less of a
> concern,
>
> but it is an uncertainty (because it could be interpreted more
> rigidly in the future)

I am not judging here, i merely stated the observation that Wikidata in 
its current form would not be capable to function as an universal 
meta-database connecting OSM with other open data sets.

To be honest - even if Wikidata was willing to change their Notability 
rules in a way that fully covers OSM (like by adding a rule declaring 
everything in OSM notable) this would still not work because it would 
also need to cover everything in any other open database OSM might be 
connected to and that quickly scales to a point where Wikidata almost 
certainly does not want to go.

> For me, criterions pro wikidata are:
> - it has a very permissive license (cc0)
> - it is openly accessible
> - it is fully downloadable as a dump (i.e. I don't have to use APIs
> which might log what I look at or limit the speed or quantity of my
> access) - there is overlap with our field of interest

You should be aware that these same criteria are fulfilled by a large 
number of other data sets, like for example almost all geodata 
published by the USGS or other US federal institutions.

> > But my question was specifically to what extent data has been
> > transferred based on wikidata ID references.  The question if such
> > data transfer happened before based on other connections has
> > nothing to do with this.
>
> Is this about reliability of the information, or about licensing
> questions?

If and how wikidata tags in OSM are used by Mappers to transfer 
additional information from Wikidata to OSM is important to know i 
think.  I have no specific hypothesis here.  But obviously such 
transfer can result both in legal and quality concerns.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-it] Fire hydrant voting

[paolo bubici]

Martin,
quindi potrebbe essere prematura metterla ai voti? Ci bruciamo anche gli
attacchi di mandata :-) 

Bubix

Il 11/ott/2017 15:58, "Martin Koppenhoefer"  ha
scritto:

>
>
> 2017-10-11 15:39 GMT+02:00 paolo bubici :
>
>> Ma la proposta di Martin non è stata oggetto di votazione?
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Dry_riser_inlet
>>
>>
>
>
> si, ma non è un idrante, è il contrario (un punto da immettere acqua).
>
> 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] Fire hydrant voting

[Martin Koppenhoefer]

2017-10-11 15:39 GMT+02:00 paolo bubici :

> Ma la proposta di Martin non è stata oggetto di votazione?
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Dry_riser_inlet
>
>


si, ma non è un idrante, è il contrario (un punto da immettere acqua).

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

Re: [Talk-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[Martin Koppenhoefer]

2017-10-11 15:28 GMT+02:00 Andrea Musuruane :

> Quindi rimaniamo con waterway=river che può indicare sia torrenti che
> fiumi. Pertanto, bisognerebbe inserire nel tag name il nome completo. Cosa
> che, tra l'altro, già facciamo sempre in altri contesti.
>


potremmo anche usare un'altro tag per mettere questo, come sempre si fa in
altri contesti ;-)
per esempio waterway:it=torrente

I francesi per esempio usano:
https://taginfo.openstreetmap.org/keys/school%3AFR
Da noi comincia a diffondersi restaurant:type:it
https://taginfo.openstreetmap.org/keys/restaurant%3Atype%3Ait

Ci sono anche pocchissimi waterway:type (e sopratutto pocchisimi valori che
non sono "observed")
https://taginfo.openstreetmap.org/keys/waterway%3Atype#values

Quindi se si riuscissi a creare una descrizione per ogni tipo di corso
d'acqua che vogliamo descrivere, potremmo anche creare un nuovo set di
valori internazionali (per sottotipi di corsi d'acqua, non per sostituire
la classificazione di waterway).

A me piace di più l'ultima ipotesi. Per esempio il torrente adirittura ha
una pagina nella wikipedia tedesca:
https://de.wikipedia.org/wiki/Torrente_(Sturzbach)


Sono anch'io per il nome completo, ma non sono sicuro che "fiume" e
"torrente" ne fanno parte.

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

Re: [Talk-it] Fire hydrant voting

[paolo bubici]

Ma la proposta di Martin non è stata oggetto di votazione?

https://wiki.openstreetmap.org/wiki/Proposed_features/Dry_riser_inlet

Il 11/ott/2017 11:08, "Martin Koppenhoefer"  ha
scritto:

> innanzitutto concordo con te, è proprio pessimo non partecipare nella
> discussione e poi presentarsi con un "no".
>
> Nello specifico, ammetto che non essendo un esperto per idranti e vvf,
> avevo deciso di non seguire la discussione nel dettaglio (pensavo chi fosse
> più esperto di me avrebbe gestito e poi concluso la facenda).
> Dopo aver sentito del rischio di fallimento del voto mi sono letto i
> commenti, e alcuni mi sembravano anche sensati:
>
>
> 1. perché dobbiamo cambiare il tag da "fire_hydrant:*" a "*" se ci sono
> già millioni di questo tag, se non cambia nient'altro che togliere il
> prefisso?
>
> 1.1. per esempio da fire_hydrant:diameter a diameter? Questo in
> particolare, perché "diameter" può riferirsi sempre (nel caso di tubi) ad
> un diametro esterno o interno. Penso sarebbe stato meglio specificare
> direttamente se "inner" o "outer" nella chiave (anche se per un VVF è
> chiaro se si riferisca ad un diametro interno, cosa sarebbe più chiaro con
> un prefisso "fire_hydrant"), sicuramente nella descrizione, per evitare
> confusioni.
> Ci sono sempre argomenti sia per il tag generico, che per quello specifico
> / speciale, in particolare la versione generica comporta probabilmente che
> più persone ottengono il tag nel loro database produttivo (se filtrano
> secondo i tag), mentre quello con prefisso porta all'eliminazione di questo
> tag nel estratto (se uno non scelga coscientemente di tenerlo). Per i
> dettagli degli idranti (tema altamente specialistico), penso sarebbe meglio
> il secondo caso.
>
> 1.2 fire_hydrant:type a fire_hydrant
> è più breve, ma non comporta altri vantaggi, io ci ripenserei
>
> 1.3 fire_hydrant:position a "location":
> Ci sono già 311 958 fh position, con valori principali "green",
> "sidewalk", "lane"
> In location i valori principali sono "underground", "outdoor",
> "overground", "indoor", "kiosk", "roof", "overhead"
> Sono un po' indeciso, ma penso si potrebbe anche tenere i due tag, visto
> che non si usano gli stessi valori potrei presumere che trattano di
> proprietà simili ma non uguali (differente livello di dettaglio, foco
> diverso).
>
>
> Comunque, il lavoro non è stato in vano, avete fatto un lavoro di
> documentazione di tanti aspetti del tema, e se uno volesse, cambiare alcuni
> dei valori o chiavi in altre parole non mi sembra così importante ne
> oneroso. Ci sono una marea di nuovi tags che non sembrano contestati. E'
> chiaro, cambiare dei tags che sono in grande uso (millioni) richiede delle
> motivazioni forti, non si fa soltanto perché il nuovo tag è un po' più
> bello ma non ci sono altri problemi.
> Non ti scoraggiare, mi sa che devi discutere un'altro po' con i nuovi
> arrivati e forse fare altri compromessi nel dettaglio (tipo mantenere il
> prefisso sul nome del tag) per imbarcarvi tutti insieme in un nuovo schema
> di tagging migliore ;-)
>
> 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-se] Ändra linknummer på E-vägar

[David Olsson]

Hejsan,

Känner mig relativt säker på att jag använde fel termer också alt bara
blandade ihop saker. En ny "TL;DR" hade varit att inte använda undernummer
i "ref" istället för att börja snacka om linknummer osv och bara använda
benämningen huvudnummer och undernummer (termer som används i NVDB). Så det
är inte enbart påfarter och avfarter som har undernummer som är taggade med
huvudnummer+undernummer.

T.ex E4.26 har "E4" som huvudnummer i NVDB och 26 ligger i en annan kolumn
vid namn undernummer. Så i exemplet med E4.26 så är det i dagsläget:
"ref" : "E4.26" - huvudnummer+undernummer.
Förslag till ändring:
"ref" : "E4" - huvudnummer
"official_ref" : "E4.26" - undernummer

Uttrycket att det är rådande praxis att använda skyltade nummer (E4 och
inte E4.26) inuti "ref" är jag inte så säker på mer än jag hörde det från
Minh (Mapbox-OSRM) som finns i en kommentar på github-issuen i trådstarten.
Samtidigt finns det runt 1800 saker som har undernummer i Sverige inuti
"ref".

Har eventuellt möjlighet att be några bekanta att hjälpa mig tagga om ref
som innehåller undernummer, men det är inget jag vill göra utan att ha en
diskussion kring det först.

Mvh
David

2017-10-11 15:12 GMT+02:00 Essin :

> Hej!
>
> Först en terminologifråga: Inom OSM brukar link användas om påfarts- och
> avfartsramper, t ex motorway_link. Det som diskuteras här kallas i en
> otydligt skriven och dåligt källbelagd Wikipediaartikel [1] för "grenväg",
> så jag använder den termen i brist på bättre.
>
> På ramper taggas normalt inte ref= i OSM även om numret skyltas utan
> streckad ram och det står så i NVDB. Undantaget är när man måste följa
> rampen för att passera trafikplatsen längs vägen med ett visst nummer. Ett
> alternativ för att tagga hur det skyltas är destination:ref= och
> destination:ref:to= [2] (den senare motsvarar streckad ram). E 4.26 är så
> kort att det är möjligt att hela sträckan skyltas som en ramp.
>
> Jag är ganska övertygad om att nummer på grenvägar samt sekundära och
> tertiära länsvägar bör finnas i OSM (se [3]), men jag är mer agnostisk om
> hur de ska taggas. "Tagging for the renderer (and routing software)" [4] är
> en aspekt som är relevant i sammanhanget. Det finns ju också andra saker i
> OSM som har namn eller nummer som inte skyltas, till exempel små
> vattendrag. När den stora skogsbranden i Västmanland pågick sas det på
> nyheterna att branden var på väg att korsa väg 668 i riktning Norberg, och
> då var det praktiskt att snabbt kunna kolla i OSM vilken väg det var.
>
> Om en omtaggning ska göras vore det bra om den kan göras mekaniskt på en
> gång för hela Sverige, så att vi inte hamnar i ett läge där olika delar av
> landet tillämpar olika konventioner.
>
> [1] https://sv.wikipedia.org/wiki/Grenv%C3%A4g
> [2] https://wiki.openstreetmap.org/wiki/Proposed_features/
> Destination_details
> [3] https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/List_of_roads
> [4] https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer
>
> OSM-hälsningar,
> Essin
>
> Den 28 september 2017 10:37 skrev David Olsson :
>
>> Streckade skyltar är inte samma sak i.o.m det är var man är på väg till
>> om man fortsätter på vägen (men lite OT). T.ex E4.26 är fortfarande
>> Europaväg 4 inuti nvdb. Hittade även flera streetviewbilder där skyltarna
>> längst rutten stod som E4 (inte streck)
>>
>> OSRM (Open Source Routing Machine) använder "ref" (och vägnamn, vilket
>> ledde till min undermåliga formulering tidigare) för att skapa
>> instruktionerna till användarna. Och då är det viktigt att användarna får
>> instruktioner som matchar informationen i verkligheten (som skyltar och
>> dess nummer). Så när man kör på en Europaväg så behöver det stå numret och
>> inte nummer + undernummer i.o.m skyltarna enbart visar huvudnumret. (Det
>> var här jag blandade ihop med vägnamn, osrm använder vägnamn och/eller
>> 'ref' för att bygga instruktionen).
>>
>> Det verkar också ha varit standard att tagga skylt-info som ref (Med
>> skyltinfo menar jag att i detta fall enbart skriva E4 och inte E4.26) och
>> sedan lägga till hela numret, inkl undernummer, i official_ref. Det känns
>> mest naturligt att lägga det i official_ref då undernumret är hos nvdb.
>>
>> "The prevailing practice in OpenStreetMap is to reserve the ref tag for
>> signposted route numbers. "
>>
>> Så ta bort undernummer på vägar inuti 'ref' och sedan lägga till en tag,
>> official_ref som inkluderar undernummer. Så blir det väl perfekt? Vill
>> givetvis inte gå rogue och börja tagga om utan att fråga här först. Men iom
>> det är rådande praxis att 'ref' ska vara skyltade vägnummer så borde vägar
>> vars nummer inkluderar undernummer taggas om, och man bör ha detta i åtanke
>> vid nya vägar.
>>
>> Hoppas jag förtydligade mig lite.
>>
>> 2017-09-28 1:07 GMT+02:00 Andreas Vilén :
>>
>>> Fast de vägar som är länkvägar är väl inte skyltade E4 osv med ifyllda
>>> ramar utan streckade? Då dessa vägsträckor inte är 

Re: [Talk-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[Andrea Musuruane]

Ciao Marco,

2017-10-11 11:37 GMT+02:00 mbranco :

> Domanda banale, ma non trovo discussioni precedenti a riguardo:
> vedo che parecchi corsi d'acqua hanno il name che inizia con "Fiume" o
> "Torrente", e parecchi altri no;
> per es. il Po si chiama solo "Po", il Piave si chiama "Fiume Piave".
>
> L'altra cosa che ho notato è che in Italia ci sono moltissimi fiumi
> (waterway=river): è vero che c'è ambiguità tra stream e river, però almeno
> nei casi dove il name="Torrente ..." , mi sembrerebbe giusto mettere
> waterway=stream (oltre che toghliere dal nome "Torrente").
>
> Cosa ne pensate?
>

Sicuramente è sbagliato mettere waterway=stream se il nome inizia per
Torrente. Perché "[use] waterway=stream for small waterways that can be
jumped across by a fit adult."
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver

Quindi rimaniamo con waterway=river che può indicare sia torrenti che
fiumi. Pertanto, bisognerebbe inserire nel tag name il nome completo. Cosa
che, tra l'altro, già facciamo sempre in altri contesti.

Ciao,

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

Re: [Talk-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[Martin Koppenhoefer]

2017-10-11 11:37 GMT+02:00 mbranco :

> Domanda banale, ma non trovo discussioni precedenti a riguardo:
> vedo che parecchi corsi d'acqua hanno il name che inizia con "Fiume" o
> "Torrente", e parecchi altri no;
> per es. il Po si chiama solo "Po", il Piave si chiama "Fiume Piave".
>


non so se fa parte del nome, in certi casi sicuramente no. Nessuno dice "il
fiume Tevere", si dice "il Tevere".



>
> L'altra cosa che ho notato è che in Italia ci sono moltissimi fiumi
> (waterway=river): è vero che c'è ambiguità tra stream e river,



veramente, c'è una regola (che non mi convince troppo, ma c'è "da sempre"):
quando puoi saltare sopra è un stream, altrimenti un river.

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

Re: [Talk-ca] COMS2200 Ottawa, Carleton University

[Tracey P. Lauriault]

Thank you.
Lets finish this assignment and then regroup to discuss whether or not this
should be done again next year, and if so the best way to do it.

The students will need to put together a small reflection piece on the
process, that should help.  We will have identified numerous issues and
error types, and we will have learned something about students and the OSM
community.

I am travelling quite a bit this month, if I am here I will attend the next
local.  Please let me know when and where they are.

Cheerio
Tracey

On Wed, Oct 11, 2017 at 8:30 AM, James  wrote:

> I think some people are missing the point of the class by saying: Go map
> an african village.
>
> The point was to have students go outside and take photos of real world
> items(surveying) and upload them to mapillary
> Then the students take the mapillary photo key and add it to the item in
> OSM
> They are supposed to learn about deriving information from
> something(photo, text,etc)
>
> As I've said to Tracey, I welcome the project, maybe we will get some new
> mappers out of it, but they are new mappers(we all started out new at one
> point and we've made errors in the past) and if they can learn from the
> feedback; all the better.
>
> On Wed, Oct 11, 2017 at 8:22 AM, john whelan 
> wrote:
>
>> This is primarily to Tracey ca-talk has been cced.
>>
>> There are a number of issues here.
>>
>> First OSM is growing up.  No longer is it a bunch of mappers who use the
>> edit tools or web page to view the map.  The data is live and snapshots are
>> taken by various players including OSMAND at points in time.  This can be
>> once a month so if there are a small number of mistakes not a big deal.  If
>> there are a large number in the snapshot then OSMAND users are stuck with
>> them until the next off line map is made available.  Because of bandwidth
>> costs both to the end user and to OSMAND it can be two or three months
>> before the errors are cleared.
>>
>> Second the email over Frederick's signature is extremely polite for
>> Frederick.  He wrote the book on OSM and is part of the group currently
>> looking at whether we need a formal policy for handling edits by groups of
>> organised mappers.  The DWG working group is the highest central authority
>> within OSM and is concerned with data quality or vandalism.  I think the
>> Carlton students edits show there is a very definite need.  A number of
>> mappers including myself were hoping there wouldn't be a need for something
>> quite so formal.  Note to Frederick if you read this change my response to
>> the survey.
>>
>> Third OpenStreetMap is very rich in what can be mapped.  In an urban area
>> it can be very complex to map.  For example currently there is a push
>> within OpenStreetMap to add more information for the disabled.
>> http://wiki.openstreetmap.org/wiki/Disabilities but exactly how one adds
>> tactile_paving = yes correctly is something I still have to work out.  The
>> City of Ottawa is currently adding  tactile_paving at many road
>> junctions and for blind people it is very useful as many junctions now have
>> slopes rather than curb stones which makes it difficult to know where the
>> edge of the sidewalk is for a blind person.
>>
>> In general I'd start students mapping either on a test server or on a HOT
>> project but it would need thinking about which one to map.  Adding
>> information for the disabled would also work in that it adds value and is a
>> small subset of mapping.  The HOT projects have a validation process so the
>> mapping can be verified and is used to large numbers of students mapping in
>> a small area.  Typically they restrict what is requested to be mapped.
>> http://tasks.hotosm.org/project/2657 is an example but it would not be
>> ideal for 150 mappers at once.  I'd need to discuss with someone such as
>> Pete Masters what would be ideal.  It's armchair mapping but that reduces
>> the number of variables.  OSM can be edited in many ways.  Unfortunately
>> some which use smartphones and GPS are not especially accurate and near
>> tall buildings they can be a hundred meters out. I assume
>> http://learnosm.org/ was brought to the attention of the students?
>> http://wiki.openstreetmap.org/wiki/Map_Features and taginfo.
>>
>> It's also interesting in the context of the Statistics Canada building
>> project, data quality is important to Stats Canada and one reason I felt
>> the original project was at risk of not being a success was the possibility
>> that a large number of new mappers would be difficult to train.  Just
>> adding tags onto imported buildings was much simpler and much less error
>> prone.
>>
>> I can probably make myself available to brief the students about
>> OpenStreetMap unfortunately I have some domestic issues at the moment which
>> rules out the next couple of days.  Bug me if this would be of use.
>>
>> Cheerio John
>>
>>
>>
>>
>> On 10 October 2017 at 23:08, Steve Singer 

Re: [Talk-se] Ändra linknummer på E-vägar

[Essin]

Hej!

Först en terminologifråga: Inom OSM brukar link användas om påfarts- och
avfartsramper, t ex motorway_link. Det som diskuteras här kallas i en
otydligt skriven och dåligt källbelagd Wikipediaartikel [1] för "grenväg",
så jag använder den termen i brist på bättre.

På ramper taggas normalt inte ref= i OSM även om numret skyltas utan
streckad ram och det står så i NVDB. Undantaget är när man måste följa
rampen för att passera trafikplatsen längs vägen med ett visst nummer. Ett
alternativ för att tagga hur det skyltas är destination:ref= och
destination:ref:to= [2] (den senare motsvarar streckad ram). E 4.26 är så
kort att det är möjligt att hela sträckan skyltas som en ramp.

Jag är ganska övertygad om att nummer på grenvägar samt sekundära och
tertiära länsvägar bör finnas i OSM (se [3]), men jag är mer agnostisk om
hur de ska taggas. "Tagging for the renderer (and routing software)" [4] är
en aspekt som är relevant i sammanhanget. Det finns ju också andra saker i
OSM som har namn eller nummer som inte skyltas, till exempel små
vattendrag. När den stora skogsbranden i Västmanland pågick sas det på
nyheterna att branden var på väg att korsa väg 668 i riktning Norberg, och
då var det praktiskt att snabbt kunna kolla i OSM vilken väg det var.

Om en omtaggning ska göras vore det bra om den kan göras mekaniskt på en
gång för hela Sverige, så att vi inte hamnar i ett läge där olika delar av
landet tillämpar olika konventioner.

[1] https://sv.wikipedia.org/wiki/Grenv%C3%A4g
[2]
https://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details
[3] https://wiki.openstreetmap.org/wiki/WikiProject_Sweden/List_of_roads
[4] https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

OSM-hälsningar,
Essin

Den 28 september 2017 10:37 skrev David Olsson :

> Streckade skyltar är inte samma sak i.o.m det är var man är på väg till om
> man fortsätter på vägen (men lite OT). T.ex E4.26 är fortfarande Europaväg
> 4 inuti nvdb. Hittade även flera streetviewbilder där skyltarna längst
> rutten stod som E4 (inte streck)
>
> OSRM (Open Source Routing Machine) använder "ref" (och vägnamn, vilket
> ledde till min undermåliga formulering tidigare) för att skapa
> instruktionerna till användarna. Och då är det viktigt att användarna får
> instruktioner som matchar informationen i verkligheten (som skyltar och
> dess nummer). Så när man kör på en Europaväg så behöver det stå numret och
> inte nummer + undernummer i.o.m skyltarna enbart visar huvudnumret. (Det
> var här jag blandade ihop med vägnamn, osrm använder vägnamn och/eller
> 'ref' för att bygga instruktionen).
>
> Det verkar också ha varit standard att tagga skylt-info som ref (Med
> skyltinfo menar jag att i detta fall enbart skriva E4 och inte E4.26) och
> sedan lägga till hela numret, inkl undernummer, i official_ref. Det känns
> mest naturligt att lägga det i official_ref då undernumret är hos nvdb.
>
> "The prevailing practice in OpenStreetMap is to reserve the ref tag for
> signposted route numbers. "
>
> Så ta bort undernummer på vägar inuti 'ref' och sedan lägga till en tag,
> official_ref som inkluderar undernummer. Så blir det väl perfekt? Vill
> givetvis inte gå rogue och börja tagga om utan att fråga här först. Men iom
> det är rådande praxis att 'ref' ska vara skyltade vägnummer så borde vägar
> vars nummer inkluderar undernummer taggas om, och man bör ha detta i åtanke
> vid nya vägar.
>
> Hoppas jag förtydligade mig lite.
>
> 2017-09-28 1:07 GMT+02:00 Andreas Vilén :
>
>> Fast de vägar som är länkvägar är väl inte skyltade E4 osv med ifyllda
>> ramar utan streckade? Då dessa vägsträckor inte är en del av själva e-vägen
>> utan har ett internt nummer bör dessa nog inte skyltas med huvudnumret.
>>
>> Jag tror att skälet till att dessa nummer, liksom de sekundära
>> länsvägarna, börjat användas mer i media är för att de renderas på osm och
>> även här och där på eniro och andra kartor. Det vore då i min mening synd
>> att åter dölja dessa. Men det är egentligen helt rätt att de passar bättre
>> i official_ref eller unsigned_ref.
>>
>> /Andreas
>>
>> Skickat från min iPhone
>>
>> 25 sep. 2017 kl. 09:35 skrev David Olsson :
>>
>> Lekmanna-miss av mig. Jag syftar såklart på vägnumret och vad som finns i
>> ref-taggen. Och förstår jag allt rätt så ska "ref" vara i princip det som
>> står på skylten. (E4 i detta fall).
>> Så ändra ref : E 4.26 till enbart ref: E 4 och sedan lägga till en
>> "official_ref : E 4.26" tycks vara den bästa lösningen, likt 1ec5 nämnde i
>> kommentaren på github.
>>
>> Ber om ursäkt för missen, jag som tyckte E4 är namnet på vägen när det
>> egentligen är numret.
>>
>> /David
>>
>> On 24 Sep 2017 20:12, "Andreas Vilén"  wrote:
>>
>>> Skilj på namn och nummer. De här vägarna har dessa som officiella
>>> nummer. De skyltas vad jag vet inte men används mer och mer i media.
>>> Däremot har de ofta helt andra namn eller inga namn alls. Namnen kan 

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Martin Koppenhoefer]

2017-10-11 13:42 GMT+02:00 Christoph Hormann :

> * Wikidata is definitely not suited as an universal meta-database
> connecting OSM with other open data sets.  This is because of the
> Notability concept (https://www.wikidata.org/wiki/Wikidata:Notability)
> which practically means the vast majority of the >500 million tagged
> features in OSM will never be able to get a Wikidata ID and will
> therefore never be able to be connected to other data sets through
> Wikidata.
>


>From what I have seen so far, this should probably be less of a concern,
but it is an uncertainty (because it could be interpreted more rigidly in
the future), I agree. Requirements seem to be much lower than they are for
wikipedia inclusion, for one because a link to any of these wikimedia
projects is sufficient: Wikipedia, Wikivoyage, Wikisource, Wikiquote,
Wikinews, Wikibooks, Wikidata, Wikispecies, Wikiversity, or Wikimedia
Commons (this paragraph is followed by some clarification and limitation).
In other words, if you want to save your pet wikidata object from deletion
it is sufficient to take a picture of it and upload it to wm commons.

There's also a very soft criterion in the next paragraph which allows
object that "[refer] to an instance of a *clearly identifiable conceptual
or material entity*. The entity must be notable, in the sense that it *can
be described using serious and publicly available references*."
It requires references to be "serious" (how subjective is this?).

On the other hand, even stuff like objects for osm tags don't get removed:
https://www.wikidata.org/wiki/Q29637965
likely because it fulfills a structural need.




>
> > * What is the qualification of Wikidata for having its IDs in OSM
> > (both for wikidata=* and X:wikidata=*)?  Is there a particular
> > objective criterion that qualifies it?  Would there be other external
> > IDs that would also qualify under these criteria?  Is there a limit
> > in the number of different external IDs OSM is going to accept?
>


is it something we have to decide now, or can we wait until we can see how
many external IDs mappers actually put into OSM, and whether this can
become a serious problem?
For me, criterions pro wikidata are:
- it has a very permissive license (cc0)
- it is openly accessible
- it is fully downloadable as a dump (i.e. I don't have to use APIs which
might log what I look at or limit the speed or quantity of my access)
- there is overlap with our field of interest



>
> > > * To what extent has there been information transferred
> > > systematically from Wikidata and Wikipedia to OSM based on wikidata
> > > ID references (like adding names in different languages).  As
> > > others have explained this would be legally problematic and it
> > > would be important to know how common this is.
> >
> > I agree that there are questions about OSM's acceptance of labels and
> > statements copied from Wikidata, though I would've expected this
> > phenomenon to be at least as common with Wikipedia long before the
> > introduction of the wikidata tag.
>
> But my question was specifically to what extent data has been
> transferred based on wikidata ID references.  The question if such data
> transfer happened before based on other connections has nothing to do
> with this.
>


Is this about reliability of the information, or about licensing questions?
As wikidata is published under cc0, the latter shouldn't matter here, it is
the wikimedia foundation that guarantees that they can release this data as
cc0, no?

Although, admittedly, wikimedia foundation themselves have not yet formed a
definitive view on database protection:
https://meta.wikimedia.org/wiki/Wikilegal/Database_Rights
Disclaimer: "Note: This page shares the Wikimedia Foundation’s preliminary
perspective on a legal issue. This page is not final - if you have
additional information, or want to provide a different perspective, please
feel free to expand or add to it."
And there are also some sentences on this page (
https://meta.wikimedia.org/wiki/Wikilegal/Database_Rights#Conclusion ) that
read like WMF would be suggesting to copy protected material from EU
databases "under the radar": "Extraction and use of data should be kept to
a minimum and *limited to unprotected material, such as uncopyrightable
facts and short phrases*, rather than extensive text. For EU databases,
bots or other automated ways of extracting data should also be avoided
because of the Directive’s prohibition on “repeated and systematic
extraction” of even insubstantial amounts of data."

First, under the database directive there is no "unprotected material such
as ... facts and short phrases", and secondly, if you take information from
a database to build another database like wikidata it is a given that all
users together likely do "repeated and systematic extraction", regardless
of using a bot or doing it "manually".

Cheers,
Martin
___
talk mailing list

Re: [Talk-ca] COMS2200 Ottawa, Carleton University

[James]

I think some people are missing the point of the class by saying: Go map an
african village.

The point was to have students go outside and take photos of real world
items(surveying) and upload them to mapillary
Then the students take the mapillary photo key and add it to the item in OSM
They are supposed to learn about deriving information from something(photo,
text,etc)

As I've said to Tracey, I welcome the project, maybe we will get some new
mappers out of it, but they are new mappers(we all started out new at one
point and we've made errors in the past) and if they can learn from the
feedback; all the better.

On Wed, Oct 11, 2017 at 8:22 AM, john whelan  wrote:

> This is primarily to Tracey ca-talk has been cced.
>
> There are a number of issues here.
>
> First OSM is growing up.  No longer is it a bunch of mappers who use the
> edit tools or web page to view the map.  The data is live and snapshots are
> taken by various players including OSMAND at points in time.  This can be
> once a month so if there are a small number of mistakes not a big deal.  If
> there are a large number in the snapshot then OSMAND users are stuck with
> them until the next off line map is made available.  Because of bandwidth
> costs both to the end user and to OSMAND it can be two or three months
> before the errors are cleared.
>
> Second the email over Frederick's signature is extremely polite for
> Frederick.  He wrote the book on OSM and is part of the group currently
> looking at whether we need a formal policy for handling edits by groups of
> organised mappers.  The DWG working group is the highest central authority
> within OSM and is concerned with data quality or vandalism.  I think the
> Carlton students edits show there is a very definite need.  A number of
> mappers including myself were hoping there wouldn't be a need for something
> quite so formal.  Note to Frederick if you read this change my response to
> the survey.
>
> Third OpenStreetMap is very rich in what can be mapped.  In an urban area
> it can be very complex to map.  For example currently there is a push
> within OpenStreetMap to add more information for the disabled.
> http://wiki.openstreetmap.org/wiki/Disabilities but exactly how one adds
> tactile_paving = yes correctly is something I still have to work out.  The
> City of Ottawa is currently adding  tactile_paving at many road junctions
> and for blind people it is very useful as many junctions now have slopes
> rather than curb stones which makes it difficult to know where the edge of
> the sidewalk is for a blind person.
>
> In general I'd start students mapping either on a test server or on a HOT
> project but it would need thinking about which one to map.  Adding
> information for the disabled would also work in that it adds value and is a
> small subset of mapping.  The HOT projects have a validation process so the
> mapping can be verified and is used to large numbers of students mapping in
> a small area.  Typically they restrict what is requested to be mapped.
> http://tasks.hotosm.org/project/2657 is an example but it would not be
> ideal for 150 mappers at once.  I'd need to discuss with someone such as
> Pete Masters what would be ideal.  It's armchair mapping but that reduces
> the number of variables.  OSM can be edited in many ways.  Unfortunately
> some which use smartphones and GPS are not especially accurate and near
> tall buildings they can be a hundred meters out. I assume
> http://learnosm.org/ was brought to the attention of the students?
> http://wiki.openstreetmap.org/wiki/Map_Features and taginfo.
>
> It's also interesting in the context of the Statistics Canada building
> project, data quality is important to Stats Canada and one reason I felt
> the original project was at risk of not being a success was the possibility
> that a large number of new mappers would be difficult to train.  Just
> adding tags onto imported buildings was much simpler and much less error
> prone.
>
> I can probably make myself available to brief the students about
> OpenStreetMap unfortunately I have some domestic issues at the moment which
> rules out the next couple of days.  Bug me if this would be of use.
>
> Cheerio John
>
>
>
>
> On 10 October 2017 at 23:08, Steve Singer  wrote:
>
>> On Tue, 10 Oct 2017, Tracey P. Lauriault wrote:
>>
>>
>>
>> Greetings OSM mappers;
>>>
>>
>>
>> For the benefit of background to others on the list
>>
>> http://www.openstreetmap.org/user_blocks/1560
>>
>> Is an example of the block message that was sent to a bunch of users.
>>
>> (I wasn't involved in asking for or implementing the blocks or have
>> anything to do with the assignment).
>>
>> I haven't looked at the edits in any details but I will make a few
>> general comments
>>
>> 1. If one user comes into OSM and makes a few changes with issues because
>> of misunderstandings or inexperience fixing those changes isn't a big deal.
>> Most of the time 

Re: [Talk-ca] COMS2200 Ottawa, Carleton University

[john whelan]

This is primarily to Tracey ca-talk has been cced.

There are a number of issues here.

First OSM is growing up.  No longer is it a bunch of mappers who use the
edit tools or web page to view the map.  The data is live and snapshots are
taken by various players including OSMAND at points in time.  This can be
once a month so if there are a small number of mistakes not a big deal.  If
there are a large number in the snapshot then OSMAND users are stuck with
them until the next off line map is made available.  Because of bandwidth
costs both to the end user and to OSMAND it can be two or three months
before the errors are cleared.

Second the email over Frederick's signature is extremely polite for
Frederick.  He wrote the book on OSM and is part of the group currently
looking at whether we need a formal policy for handling edits by groups of
organised mappers.  The DWG working group is the highest central authority
within OSM and is concerned with data quality or vandalism.  I think the
Carlton students edits show there is a very definite need.  A number of
mappers including myself were hoping there wouldn't be a need for something
quite so formal.  Note to Frederick if you read this change my response to
the survey.

Third OpenStreetMap is very rich in what can be mapped.  In an urban area
it can be very complex to map.  For example currently there is a push
within OpenStreetMap to add more information for the disabled.
http://wiki.openstreetmap.org/wiki/Disabilities but exactly how one adds
tactile_paving = yes correctly is something I still have to work out.  The
City of Ottawa is currently adding  tactile_paving at many road junctions
and for blind people it is very useful as many junctions now have slopes
rather than curb stones which makes it difficult to know where the edge of
the sidewalk is for a blind person.

In general I'd start students mapping either on a test server or on a HOT
project but it would need thinking about which one to map.  Adding
information for the disabled would also work in that it adds value and is a
small subset of mapping.  The HOT projects have a validation process so the
mapping can be verified and is used to large numbers of students mapping in
a small area.  Typically they restrict what is requested to be mapped.
http://tasks.hotosm.org/project/2657 is an example but it would not be
ideal for 150 mappers at once.  I'd need to discuss with someone such as
Pete Masters what would be ideal.  It's armchair mapping but that reduces
the number of variables.  OSM can be edited in many ways.  Unfortunately
some which use smartphones and GPS are not especially accurate and near
tall buildings they can be a hundred meters out. I assume
http://learnosm.org/ was brought to the attention of the students?
http://wiki.openstreetmap.org/wiki/Map_Features and taginfo.

It's also interesting in the context of the Statistics Canada building
project, data quality is important to Stats Canada and one reason I felt
the original project was at risk of not being a success was the possibility
that a large number of new mappers would be difficult to train.  Just
adding tags onto imported buildings was much simpler and much less error
prone.

I can probably make myself available to brief the students about
OpenStreetMap unfortunately I have some domestic issues at the moment which
rules out the next couple of days.  Bug me if this would be of use.

Cheerio John




On 10 October 2017 at 23:08, Steve Singer  wrote:

> On Tue, 10 Oct 2017, Tracey P. Lauriault wrote:
>
>
>
> Greetings OSM mappers;
>>
>
>
> For the benefit of background to others on the list
>
> http://www.openstreetmap.org/user_blocks/1560
>
> Is an example of the block message that was sent to a bunch of users.
>
> (I wasn't involved in asking for or implementing the blocks or have
> anything to do with the assignment).
>
> I haven't looked at the edits in any details but I will make a few general
> comments
>
> 1. If one user comes into OSM and makes a few changes with issues because
> of misunderstandings or inexperience fixing those changes isn't a big deal.
> Most of the time someone will just fix them without saying anything.
> However if 30 or 300 users make lots of changes in a short amount of time
> with the same types of errors the volume present challenges.  Large scale
> edits by a bunch who are doing it as part of a course, or who are employed
> by a company to make the changes, or who are doing so as part of a
> coordinated humanitarian effort have the potential to cause problems if
> they aren't coordinated  carefully.
>
>
> 2. A big part of working in any open-source project particularly with OSM
> is that you need to communicate with the other contributors. Communication
> is a two way street, some people are better at it then others and it
> doesn't come naturally to everyone.  I would hope that a course that
> covered the contributing to open source projects (including open data
> 

Re: [Talk-ca] COMS2200 Ottawa, Carleton University

[James]

Hi Tracey, as promised I started some documentation on what errors I'm
seeing quite often. I will be updating it later during my lunch hour with
more examples:
https://github.com/TraceyLauriault/COMS2200A/issues/19

On Tue, Oct 10, 2017 at 11:08 PM, Steve Singer  wrote:

> On Tue, 10 Oct 2017, Tracey P. Lauriault wrote:
>
>
>
> Greetings OSM mappers;
>>
>
>
> For the benefit of background to others on the list
>
> http://www.openstreetmap.org/user_blocks/1560
>
> Is an example of the block message that was sent to a bunch of users.
>
> (I wasn't involved in asking for or implementing the blocks or have
> anything to do with the assignment).
>
> I haven't looked at the edits in any details but I will make a few general
> comments
>
> 1. If one user comes into OSM and makes a few changes with issues because
> of misunderstandings or inexperience fixing those changes isn't a big deal.
> Most of the time someone will just fix them without saying anything.
> However if 30 or 300 users make lots of changes in a short amount of time
> with the same types of errors the volume present challenges.  Large scale
> edits by a bunch who are doing it as part of a course, or who are employed
> by a company to make the changes, or who are doing so as part of a
> coordinated humanitarian effort have the potential to cause problems if
> they aren't coordinated  carefully.
>
>
> 2. A big part of working in any open-source project particularly with OSM
> is that you need to communicate with the other contributors. Communication
> is a two way street, some people are better at it then others and it
> doesn't come naturally to everyone.  I would hope that a course that
> covered the contributing to open source projects (including open data
> contributions) covered interacting with the community. If the course only
> wanted to give students experience with the tools then editing against a
> test or development instance of OSM would be better.
>
> The advise I would give to people new to the open source communities(and
> at times remind veterans) is believe that most people who are contributing
> are coming from a place of good intentions and to give them the benefit of
> the doubt and try to understand where they are coming from.
>
> When contributing to an open sourced project you need to take
> responsibility (as an individual) for your contributions but that doesn't
> mean they need to be, or will be perfect. No edits are perfect but people
> need to be willing to listen to and learn from feedback from other members
> of the community.
>
> Steve
>
>
>
>
>
>
>
>> I understand that students for COMS2200 have been blocked from posting to
>> OSM.
>>
>> There was also an unfortunate email sent to Carleton University by one of
>> your members that is circulating
>> through the administration from (james2...@gmail.com).
>>
>> The data are being contributed as part of an assignment described here -
>> https://github.com/TraceyLauriault/COMS2200A
>>
>> I understand that the students are making some small and some large
>> mistakes that may not meet your OSM
>> data quality standards.  The students are restricted to only be mapping
>> the Carleton University Campus.
>>
>> I wonder if it might be possible to unlock the restriction to let them
>> finish the assignment.  They should
>> be done by next week. There are 150 students.  Once the assignment is
>> complete I would gladly work with you
>> to salvage the data, delete some data, repair some data or wipe all of
>> the data.
>>
>> We apologize for this inconvenience and hope that you can be empathetic
>> and allow for the assignment to be
>> completed so that the students can be assessed.
>>
>> Also, perhaps there are a number of common errors and if you identify
>> them we may be able to fix them.
>>
>> Sincerely
>> Tracey
>>
>> --
>> Tracey P. Lauriault
>>
>> Assistant Professor Critical Media Studies and Big Data
>> Communication Studies
>> School of Journalism and Communication
>> Suite 4110, River Building
>> Carleton University
>> 1125 Colonel By Drive
>> Ottawa (ON) K1S 5B6
>> 1-613-520-2600 x7443
>> tracey.lauria...@carleton.ca
>> @TraceyLauriault
>> Skype: Tracey.P.Lauriault
>> https://carleton.ca/sjc/people-archives/lauriault-tracey/
>>
>>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>


-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-be] How we deal with those notes

[joost schouppe]

Hi Jakka,

I accidently stumbled upon them too.

A lot of them are in fact mapable, though I ignore things like 5-10 places.
Some of them make no sense, like this one:
http://www.openstreetmap.org/note/1165979

As for payed/free roadside parking, that is interesting information I
think. I've never seen it tagged actually. Apparently you can do it with
the tag parking:lane, but it seems quite unpopular to do this as
parking:lane=yes in cases where you don't have all the details. I wonder if
it makes sense to map parking:condition:both=free if you don't have all the
details. If we think it doesn't, then I guess we could just close most of
the notes on that subject.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Christoph Hormann]

On Wednesday 11 October 2017, Minh Nguyen wrote:
> Great questions. I've attempted to answer a few of them below:

Thanks for the effort - but from my point of view these answers mostly 
do not actually address the key points of my questions.  

I have made some progress getting answers to some of the core questions 
on the German forum 
(https://forum.openstreetmap.org/viewtopic.php?id=59910=3) so far 
resulting in the following conclusions from my side.

* stability of Wikidata IDs seems limited.  There seems to be a concept 
of redirects so an ID can point to a Wikidata object with a different 
ID and the object formerly under that ID is not necessarily identical 
to the one it redirects to.  To what extent re-structuring of 
information on Wikidata (that would primarily mean merging and 
splitting of Wikidata objects) leading to the creation of redirects 
happens and how much more or less common it is to OSM IDs changing i 
don't know (and given Wikidata is still very young such information 
would also be quite unreliable for the future).

* there definitely is no 1:1 relationship between Wikidata IDs and OSM 
objects in general.  In particular this is not the case for Wikidata 
objects covering several concepts that are separately mapped in OSM 
(where several features in OSM correctly refer to the same Wikidata 
ID).  Also in case of redirects in Wikidata there would be several 
Wikidata IDs corresponding to the same OSM feature (although you could 
of course formally define redirects as invalid Wikidata IDs - which 
however would further limit the stability of those IDs as explained 
above).

* Wikidata is definitely not suited as an universal meta-database 
connecting OSM with other open data sets.  This is because of the 
Notability concept (https://www.wikidata.org/wiki/Wikidata:Notability) 
which practically means the vast majority of the >500 million tagged 
features in OSM will never be able to get a Wikidata ID and will 
therefore never be able to be connected to other data sets through 
Wikidata.

There are still a lot of things that are unclear to me about the 
whole "Wikidata in OSM" subject so any further insights into this are 
welcome.  Given that Wikidata cannot function as an universal connector 
of OSM to other databases (something i was not really aware before) i 
would in particular like to re-emphasize the question:

> * What is the qualification of Wikidata for having its IDs in OSM
> (both for wikidata=* and X:wikidata=*)?  Is there a particular
> objective criterion that qualifies it?  Would there be other external
> IDs that would also qualify under these criteria?  Is there a limit
> in the number of different external IDs OSM is going to accept?

Please understand that from my side this is truly an open question, not 
a means to press for removing wikidata IDs from OSM.  But it is a 
question that needs a good answer from my point of view.  And 
deflecting by pointing to other IDs we already have in OSM like 
leftovers from imports and IDs for specific real world uses does not 
really help here.

> > * To what extent has there been information transferred
> > systematically from Wikidata and Wikipedia to OSM based on wikidata
> > ID references (like adding names in different languages).  As
> > others have explained this would be legally problematic and it
> > would be important to know how common this is.
>
> I agree that there are questions about OSM's acceptance of labels and
> statements copied from Wikidata, though I would've expected this
> phenomenon to be at least as common with Wikipedia long before the
> introduction of the wikidata tag.

But my question was specifically to what extent data has been 
transferred based on wikidata ID references.  The question if such data 
transfer happened before based on other connections has nothing to do 
with this.

We definitely have under-the-radar data imports from Wikidata, sometimes 
partly disguised by moving nodes - but the names matching in all 
inconsistencies is a clear indicator.  Like here:

http://www.openstreetmap.org/node/4996439821
http://www.openstreetmap.org/node/5073632521
http://www.openstreetmap.org/node/5121933121

But this is also a different matter unrelated to the Wikidata IDs in 
OSM.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-se] Ändringsset: 52111741

[Essin]

Hej!

Har detta åtgärdats än? Annars kan jag göra ett försök. JOSM-validatorn
(över)reagerar ofta på byggnader som verkar vara korrekt taggade enligt
Simple 3D buildings-systemet, så det är antagligen där problemet ligger.

OSM-hälsningar,
Essin

Den 19 september 2017 18:55 skrev Tobias Johansson :

> Hej
>
> Såg att en byggnad i Göteborg har oturligt ändrats (enligt mig fel). Jag
> tror inte det är pga av någon elak anledning utan bara pga inte kännedom om
> hur buildings 3d funkar.
>
> https://www.openstreetmap.org/changeset/52111741#map=19/57.70132/11.91397
>
> Jag vet inte riktigt hur man kan gå till väga för att reverta ändringen
> men någon annan kanske har koll. Jag har lagt till en kommentar på
> ändringssettet i fråga.
>
> --
> MvH Tobias Johansson
> E-Post: tj7712...@gmail.com
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-cz] Jak najít smazaná data?

[Marián Kyral]

Chtělo by to sepsat někam na wiki. Ale kam, aby se to dalo lehce najít?

Marián

-- Původní e-mail --
Od: majka 
Komu: OpenStreetMap Czech Republic 
Datum: 11. 10. 2017 13:21:00
Předmět: Re: [Talk-cz] Jak najít smazaná data?
"
Tak ještě jedna varianta, relativně jednoduchá pomocí mapy na whodidit
(http://simon04.dev.openstreetmap.org/whodidit/)



Je sice třeba prohrabávat se seznamem changesetů a ty podezřelé otevřít
jednotlivě, ale lze najít pro konkrétní území relativně rychle ten
konkrétní, který tu mazal body/cesty/relace.




Vtipné je, že RSS odsud pro kontrolu používám, ale nenapadlo mě jít online
přes mapu. Doporučuji vyzkoušet.



2017-10-11 10:57 GMT+02:00 Pavel Machek :
"On Mon 2017-10-09 14:17:24, Jan Macura wrote:
> Jinými slovy neexistuje... :-(
>
> ...

Nekdo by ho mel vytvorit :-(. Uz jsem to taky resil.
                                                                       
Pavel

"



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

Re: [Talk-cz] Jak najít smazaná data?

[majka]

Tak ještě jedna varianta, relativně jednoduchá pomocí mapy na whodidit


Je sice třeba prohrabávat se seznamem changesetů a ty podezřelé otevřít
jednotlivě, ale lze najít pro konkrétní území relativně rychle ten
konkrétní, který tu mazal body/cesty/relace.

Vtipné je, že RSS odsud pro kontrolu používám, ale nenapadlo mě jít online
přes mapu. Doporučuji vyzkoušet.

2017-10-11 10:57 GMT+02:00 Pavel Machek :

> On Mon 2017-10-09 14:17:24, Jan Macura wrote:
> > Jinými slovy neexistuje... :-(
> >
> > ...
>
> Nekdo by ho mel vytvorit :-(. Uz jsem to taky resil.
>
> Pavel
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] Nouvelle analyses Osmose sur la France : numéro de téléphone et intégration des restrictions de hauteur

[JB]

Le 11/10/2017 à 11:27, Julien Lepiller a écrit :
J'ai trouvé quelques bizarreries comme des numéros à 11 ou 12 chiffres 
(par exemple https://www.osm.org/node/4883765418
Pour celui-là en tous cas, une petite recherche indique une faute de 
frappe avec le premier 3 en trop.


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

[talk-au] Redacted roads in VIC QLD and WA

[Nick Hocking]

We have specific permissions to use certain QLD and WA data. Do we have any
such permissions for VIC, or do we have anybody who knows who to ask?

Also are there and tile servers or overlays for the QLD and WA data that we
can use to manually get the redacted road names back easily?
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-us] Texas - redacted roads.

[Nick Hocking]

Andrew wrote "I would check out the City of Austin's OpenData portal:
https://data.austintexas.gov/Locations-and-Maps/Street-Segment/t4fe-kr8c

The license is the same (PD) as when the initial building import was
completed, so you are good to go."

Thanks Andrew, I'm now replacing some names adding new roads and
neighbourhoods etc.

One interesting road is Redwil Drive.
 https://www.openstreetmap.org/#map=18/30.23189/-97.59361

Tiger has no name, Google maps and Austin-gov have Redwill Drive but google
street view shows both street signs as Reed Will Drive.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Bicipolitana

[Alessandro Palmas]

Il 11/10/2017 10:29, Gianluca Boero ha scritto:
http://www.vocepinerolese.it/articoli/2017-10-10/linea-ciclabile-da-piazza-darmi-al-polo-sportivo-retrostante-alla-stazione-olimpica-pinerolo-12737 



A Pinerolo (To) stanno realizzando questa pista ciclabile cittadina.

L'articolo cita che a Pesaro, Treviglio, San Donato Milanese, Pistoia, 
Rovigo e Lignano è o sta per essere attuata.


Qualche mappatore nei comuni citati sopra ha già visionato o mappato 
tali piste? Se si mi piacerebbe un confronto.


Io attendo la fine dei lavori e se nessuno la traccia prima di me la 
riporto.


Ciao..

Gianluca



Entro un pò in OT per ricordarvi che sabato saremo a Torino per il 
Torino mapping party (1) dove mapperemo rastrelliere, fontanelle e altri 
POI utili alla viabilità 'pedalifera' :-)
Verranno utilizzate anche le app Mapillary (io porterò la fotocamera 
sferica) e wheelmap.


Vi aspettiamo!

Alessandro Ale_Zena_IT


1) https://www.muoversiatorino.it/mapping-party/

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

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

[Minh Nguyen]

Great questions. I've attempted to answer a few of them below:

On 03/10/2017 09:56, Christoph Hormann wrote:

* To what extent has there been information transferred systematically
from Wikidata and Wikipedia to OSM based on wikidata ID references
(like adding names in different languages).  As others have explained
this would be legally problematic and it would be important to know how
common this is.


I agree that there are questions about OSM's acceptance of labels and 
statements copied from Wikidata, though I would've expected this 
phenomenon to be at least as common with Wikipedia long before the 
introduction of the wikidata tag.


Years ago, there was a campaign to add as many translations of country 
names as possible, using Wikipedia as the primary source. [1] A map 
renderer that uses these translations would logically want translations 
or transliterations for as many cities as possible, but my impression is 
that the OSM community would frown on such a massive expansion in city 
name transliterations. Instead, we can point data consumers to Wikidata 
as a source for this data.



* How stable is the identity of what can be found under a certain
Wikidata ID.  As mentioned there are cases where Wikidata aggregates
several concepts under one ID (like an administrative unit and a
populated place in case of cities/towns).  Would it be possible that
this changes?  If yes, would the original ID be re-purposed or would it
cease to exist?


To the extent that an administrative unit and populated place are 
considered separate entities, as they are for some kinds of places, 
Wikidata ideally maintains separate entities for each. The reality is 
less clear-cut, since much of Wikidata's original data on geographic and 
political entities comes from Wikipedia, which generally doesn't make 
such distinctions at the article title level. The Wikidata project aims 
to eventually create separate entities for every concept that Wikipedia 
has traditionally conflated inside the same article. Thus Wikidata 
maintains a separate entity for each Pokémon species, whereas the 
English Wikipedia combines them all into a few list articles. [2][3]


If an administrative unit or populated place (or both) ceases to exist, 
the QID remains valid, but a statement or qualifier is added to indicate 
"former" status, much like OSM's lifecycle tags (disused etc.). An 
entity may be redirected under some circumstances. For example, if the 
Wikidata community discovers that two entities are duplicates, referring 
to exactly the same concept, an editor will manually blank one in favor 
of the other, and a bot will create a redirect automatically. [4]


Many of the duplicate entities were created as a result of incorrect 
linking between Wikipedia article translations at the time Wikipedia 
article titles were being imported into Wikidata. If someone had 
translated the article "Pumpkin" from English to Pennsylvania German but 
neglected to link the English article to the Pennsylvania German one, 
Wikidata might've wound up with two entities, one linking to many 
languages including English, the other linking to only Pennsylvania 
German. Most likely the latter entity would end up redirecting to the 
former.


The English Wikipedia sees a couple dozen geographical articles renamed 
each day. [5] This is a rough estimate based on articles tagged with 
geographical coordinates. I don't know how many of these articles are 
the target of wikipedia tags in OSM -- I think that would require Yuri's 
SPARQL tool.


But the important thing to note is that a redirect on Wikipedia may not 
remain a redirect for long: editors may decide to repurpose the redirect 
page for a disambiguation page or perhaps an article on a subtlely 
different topic. If that happens, an OSM data consumer would have to 
trawl through article history to determine which article each wikipedia 
tag really meant to refer to. By comparison, since integers are cheap, 
Wikidata entities don't tend to get repurposed the way Wikipedia article 
titles do, so even a stale QID can be traced to relevant data pretty easily.



* What is the qualification of Wikidata for having its IDs in OSM (both
for wikidata=* and X:wikidata=*)?  Is there a particular objective
criterion that qualifies it?  Would there be other external IDs that
would also qualify under these criteria?  Is there a limit in the
number of different external IDs OSM is going to accept?


There are at least several other kinds of IDs that have been added in 
large numbers in the past. Off the top of my head, there are the various 
ref schemes used in conjunction with the heritage tag, GNIS feature IDs 
associated with an import of POIs in the U.S., and of course regulatory 
IDs such as ICAO/IATA.


Far from opening the floodgates to external IDs, Wikidata gives us the 
ability to limit external ID tagging. Consider that Wikidata lists seven 
different external identifiers for Hamilton County, Ohio, United 

Re: [OSM-talk-fr] Nouvelle analyses Osmose sur la France : numéro de téléphone et intégration des restrictions de hauteur

[Raphael Jacquot]

On 10/11/2017 11:27 AM, Julien Lepiller wrote:
[snip]

> Des avis ?

Bonjour

[je suis opérateur télécom]

le format des numéros en france est :

EZABPQMCDU

le format recommandé est:

+33 Z AB PQ MC DU

à noter les numéros donc ZAB = 700 sont plus longs, réservés aux modems
mobiles :

+33 Z AB PQ MC DU xx xx en métropole (P = 0 a 4)

dans les départements d'outre-mer :

+33 Z AB PQ MC DU xx x

avec P:
5: Guadeloupe
6: Guyane
7: Martinique
8: Mayotte
9: La Réunion

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

[Talk-it] Nomi di fiumi e torrenti, e (ab)uso di waterway=river

[mbranco]

Domanda banale, ma non trovo discussioni precedenti a riguardo:
vedo che parecchi corsi d'acqua hanno il name che inizia con "Fiume" o
"Torrente", e parecchi altri no;
per es. il Po si chiama solo "Po", il Piave si chiama "Fiume Piave". 

L'altra cosa che ho notato è che in Italia ci sono moltissimi fiumi
(waterway=river): è vero che c'è ambiguità tra stream e river, però almeno
nei casi dove il name="Torrente ..." , mi sembrerebbe giusto mettere
waterway=stream (oltre che toghliere dal nome "Torrente").

Cosa ne pensate?

Un saluto,
Marco

P.S. Veramente la wiki per waterway=river cita come esempi di name "River
Nile" e "River Thames", ma non mi convince... In wikipedia per es. vedo che
solo i laghi hanno nome che inizia con "Lago ..." , i fiumi non hanno
"Fiume" come inizio del nome.



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

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

Re: [Talk-lv] OpenStreetMap + Wikidata

[Mārtiņš Bruņenieks]

Sveiki!

Nav konkrētu domu, kur tas varētu notikt.
Par laiku un specifisko  tēmu arī - atkarīgs, vai ir kāds, kas atnāk
paklausīties.

Visdrīzāk vajadzētu kādu OSM kopienas sanākšanu, uz kuru es ierastos.

 Mārtiņš

2017-10-10 13:27 GMT+03:00 Rihards :

> On 2017.10.03. 16:54, Ilja Denisovs wrote:
> > Sveiki, kolēģi,
> >
> >
> > izklausās pēc jaukas tēmas (sen nebijušai) osm sanākšanai kādā
> > darbdienas vakarā. varbūt kaut kad oktobra otrajā pusē?
> >
> >
> > Piekrītu, tā ir laba ideja!
>
> Mārtiņ, vai tev bija kāda doma, kad šādu tikšanos varētu rīkot ?
> vai ir jau plāniņš, kur rīkot ?
>
> saistīti - wikidata/wikipedia satīrīšanas projekts par linkiem uz
> cilvēkiem :
> https://wiki.openstreetmap.org/wiki/Wikipedia_Link_
> Improvement_Project#Linking_to_Humans
>
> varbūt ir vērts nelabot latvijā esošos ~5 gadījumus, nodemonstrējot
> labošanu decembrī ? ;)
>
> > 2017-10-03 16:27 GMT+03:00 Rihards  > >:
> >
> > On 2017.10.03. 11 :29, Mārtiņš Bruņenieks
> wrote:
> > > Sveicināti!
> > >
> > > Vai kāds no OSM kopienas ir pamēģinājis padarboties ar Wikidata
> projektu
> > > (sasaisti ar OSM relācijām)?
> > > http://wiki.openstreetmap.org/wiki/Wikidata
> > 
> > >
> > > Diezgan brīvi orientējos Wikidata jautājumos, varētu novadīt
> workshop
> > > par šo tēmu, ja ir interesenti. Lietainie rudens vakari būtu
> piemērots
> > > laiks.
> >
> > esmu šur tur tagus palabojis, bet minimāli.
> > izklausās pēc jaukas tēmas (sen nebijušai) osm sanākšanai kādā
> > darbdienas vakarā. varbūt kaut kad oktobra otrajā pusē ?
> >
> > > Wikidata ir atvērto datu projekts, kura pirmsākumi meklējami
> Wikimedia
> > > Deutschland / vācu valodas Vikipēdijas kopienā. Ar Latvijai
> aktuālajām
> > > lietām tur darbojas vairāki Vikipēdijas latviešu valodā redaktori.
> Tomēr
> > > arvien pieaug datu apjoms, kam nav nekāda sakara ar Vikipēdiju.
> > >
> > >  Mārtiņš--
> >  Rihards
> > --
> > Best regards!
> > Ilja Denisovs
> --
>  Rihards
>
___
Talk-lv mailing list
Talk-lv@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lv

Re: [OSM-talk-fr] Nouvelle analyses Osmose sur la France : numéro de téléphone et intégration des restrictions de hauteur

[Julien Lepiller]

Bonjour,

comme je m'ennuyais hier soir, j'ai regardé ce que donnait l'analyse et 
j'ai commencé à corriger les numéros pour lesquels il manquait 
l'indicatif (+33) à peu près dans le nord de la France (vu ce que dit 
Philippe, je ne me suis pas aventuré dans les dom-com). J'ai trouvé 
quelques bizarreries comme des numéros à 11 ou 12 chiffres (par exemple 
https://www.osm.org/node/4883765418 ou 
https://www.osm.org/way/263891587. On peut les retrouver avec la requête 
overpass : http://overpass-turbo.eu/s/sgy). J'ai aussi ce nœud : 
https://www.osm.org/node/2108115408, dont le numéro est 01, que 
j'ai corrigé un peu bêtement.


Qu'est-ce que vous conseilleriez de faire pour ces numéros ? Ça me 
semble faux donc je dirais supprimer, mais je ne voudrais pas faire de 
bêtises.


Si on veut continuer dans la correction des numéros de téléphone, il y 
en a quelques uns qui utilisent des points au lieu d'espaces pour 
séparer les nombres (et qui ne sont pas trouvés par osmose même quand il 
n'y a pas d'indicatif). D'autres utilisent l'indicatif mais avec "00" au 
lieu de "+" (je ne sais pas si c'est une faute, mais autant tout 
harmoniser, non ?). Certains semblent utiliser "033" comme indicatif (ça 
collerait avec le nombre de chiffres dans un numéro de téléphone, plutôt 
qu'un numéro en 03 à 12 chiffres), d'autres juste "33".


Des avis ?

Le 2017-10-09 19:47, Frédéric Rodrigo a écrit :

Bonjour,


Sont disponible maintenant sur Osmose :


La validation des numéros des téléphones sur la Métropole et DOM (avec
les bons indicatifs)

http://osmose.openstreetmap.fr/fr/errors/?item=3092

http://osmose.openstreetmap.fr/fr/map/#item=3092


Les proposition d'intégration des restrictions de hauteur sur le
France depuis le Route 500 de l'IGN et sur le 92 depuis un fichier du
département

http://osmose.openstreetmap.fr/fr/errors/?item=8320

http://osmose.openstreetmap.fr/fr/map/#item=8320


Frédéric.



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


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

Re: [Talk-it] Fire hydrant voting

[Martin Koppenhoefer]

innanzitutto concordo con te, è proprio pessimo non partecipare nella
discussione e poi presentarsi con un "no".

Nello specifico, ammetto che non essendo un esperto per idranti e vvf,
avevo deciso di non seguire la discussione nel dettaglio (pensavo chi fosse
più esperto di me avrebbe gestito e poi concluso la facenda).
Dopo aver sentito del rischio di fallimento del voto mi sono letto i
commenti, e alcuni mi sembravano anche sensati:


1. perché dobbiamo cambiare il tag da "fire_hydrant:*" a "*" se ci sono già
millioni di questo tag, se non cambia nient'altro che togliere il prefisso?

1.1. per esempio da fire_hydrant:diameter a diameter? Questo in
particolare, perché "diameter" può riferirsi sempre (nel caso di tubi) ad
un diametro esterno o interno. Penso sarebbe stato meglio specificare
direttamente se "inner" o "outer" nella chiave (anche se per un VVF è
chiaro se si riferisca ad un diametro interno, cosa sarebbe più chiaro con
un prefisso "fire_hydrant"), sicuramente nella descrizione, per evitare
confusioni.
Ci sono sempre argomenti sia per il tag generico, che per quello specifico
/ speciale, in particolare la versione generica comporta probabilmente che
più persone ottengono il tag nel loro database produttivo (se filtrano
secondo i tag), mentre quello con prefisso porta all'eliminazione di questo
tag nel estratto (se uno non scelga coscientemente di tenerlo). Per i
dettagli degli idranti (tema altamente specialistico), penso sarebbe meglio
il secondo caso.

1.2 fire_hydrant:type a fire_hydrant
è più breve, ma non comporta altri vantaggi, io ci ripenserei

1.3 fire_hydrant:position a "location":
Ci sono già 311 958 fh position, con valori principali "green", "sidewalk",
"lane"
In location i valori principali sono "underground", "outdoor",
"overground", "indoor", "kiosk", "roof", "overhead"
Sono un po' indeciso, ma penso si potrebbe anche tenere i due tag, visto
che non si usano gli stessi valori potrei presumere che trattano di
proprietà simili ma non uguali (differente livello di dettaglio, foco
diverso).


Comunque, il lavoro non è stato in vano, avete fatto un lavoro di
documentazione di tanti aspetti del tema, e se uno volesse, cambiare alcuni
dei valori o chiavi in altre parole non mi sembra così importante ne
oneroso. Ci sono una marea di nuovi tags che non sembrano contestati. E'
chiaro, cambiare dei tags che sono in grande uso (millioni) richiede delle
motivazioni forti, non si fa soltanto perché il nuovo tag è un po' più
bello ma non ci sono altri problemi.
Non ti scoraggiare, mi sa che devi discutere un'altro po' con i nuovi
arrivati e forse fare altri compromessi nel dettaglio (tipo mantenere il
prefisso sul nome del tag) per imbarcarvi tutti insieme in un nuovo schema
di tagging migliore ;-)

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

Re: [Talk-it] Bicipolitana

[Volker Schmidt]

So di sicuro che a Pesaro è stata implementata (sono stato in contatto con
l'ideatrice). Le linee sono mappate come relazioni con network=lcn.
Mi sembra corretto.

2017-10-11 10:29 GMT+02:00 Gianluca Boero :

> http://www.vocepinerolese.it/articoli/2017-10-10/linea-cicla
> bile-da-piazza-darmi-al-polo-sportivo-retrostante-alla-
> stazione-olimpica-pinerolo-12737
>
> A Pinerolo (To) stanno realizzando questa pista ciclabile cittadina.
>
> L'articolo cita che a Pesaro, Treviglio, San Donato Milanese, Pistoia,
> Rovigo e Lignano è o sta per essere attuata.
>
> Qualche mappatore nei comuni citati sopra ha già visionato o mappato tali
> piste? Se si mi piacerebbe un confronto.
>
> Io attendo la fine dei lavori e se nessuno la traccia prima di me la
> riporto.
>
> Ciao..
>
> Gianluca
>
> --
> Gianluca Boero
>
>
> ___
> 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-cz] Jak najít smazaná data?

[Pavel Machek]

On Mon 2017-10-09 14:17:24, Jan Macura wrote:
> Jinými slovy neexistuje... :-(
> 
> Záložka Historie na OSM.org je nepoužitelná, protože je to plné právě těch
> changesetů, které kombinují Londýn s Kuala Lumpur...
> Metoda vybrat si ze seznamu změn jen ty s lokálním bboxem může snadno ten
> hledaný changeset minout, protože mohlo jít právě o trochu hromadnější
> editaci ve více obcích, bbox může být třeba přes celý kraj nebo republiku
> (zvlášť, když hodlám hledat data za posledních půl roku).
> 
> Ten nástroj od achavi mi nenachází ani changesety, které jsem dělal včera
> já.. Možná jsem nepochopil k čemu je a jak funguje.. ?
> 
> Co třeba nástroj, který by pro zadané území našel ne bbox celého
> changesetu, ale intersect s geometriemi, které se skutečně v té vybrané
> oblasti nachází či kdykoliv dříve nacházely? To by nebylo? :-)

Nekdo by ho mel vytvorit :-(. Uz jsem to taky resil.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

Re: [Talk-lt] Naujas žemėlapis - vektorinis žemėlapis!

[Ramas]

Online stiliaus redaktorius yra žiauriai geras dalykas :)
Man rodos LT tokio niekas neturi...

2017-10-10 15:04 GMT+03:00 Tomas Straupis :

> Sveiki
>
>   Dar norėčiau paminėti, kad jei norite pažaisti su vektorinio
> žemėlapio stiliais, galite tą padaryti tiesiog sekdami nuorodas
> vektorinio žemėlapio repozitorijos wikyje:
>   https://github.com/openmaplt/vector-map/wiki
>
>   Apačioje yra dvi nuorodos: viena į standartinį, kita į hibridinį
> (ortofoto+kelių vektoriai, pavadinimai, lankytinos vietos).
>
>   Spaudžiate norimą nuorodą ir jūsų naršyklėje atsidarys atitinkamas
> žemėlapis. Dešinėje matysite vaizdą, kairėje - visus sluoksnius ir
> braižymo taisykles (spalvos, dydžiai, šriftai ir t.t.). Kairėje
> keičiate ką norite ir dešinėje iš karto matote rezultatą.
>
>   Nebijokite keisti, rezultatas yra tik jūsų naršyklėje. Taigi tikrai
> nesugadinsite openmap.lt žemėlapių :-)
>
>   Jei turite klausimų - drąsiai klauskite čia.
>
> --
> Tomas
>
> ___
> Talk-lt mailing list
> Talk-lt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lt
>
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Cascafico Giovanni]

IMHO l'operatore (quello che una volta in montagna si chiamava "lo
stradino") che sistema fisicamente il sentiero/strada può essere un
tag delle way. E può anche convivere con l'operatore delle relation
che invece si occupa della segnaletica, ovvero dell'aspetto non fisico
dell'elemento.




Il 11 ottobre 2017 09:57, Martin Koppenhoefer 
ha scritto:
>
>
> sent from a phone
>
>> On 11. Oct 2017, at 09:51, Alfredo Gattai  wrote:
>>
>> Quindi se per ipotesi esiste un percorso che ha il numero 111 e si chiama 
>> "Via della Transumanza" si crea una relazione con
>>
>> ref=111
>> name=Via della Transumanza
>>
>> sulle singole way non devono essere ripetuti.
>
>
> questo ovviamente solo quando tutto il percorso si chiama così, altrimenti i 
> nomi vanno sui way (il nome della relazione (insieme di vie e sentieri che 
> costituiscono il percorso) è quello del tag name sulla relazione, il nome del 
> singolo sentiero e della singola strada va sul way)
>
> 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-it] Bicipolitana

[Gianluca Boero]

http://www.vocepinerolese.it/articoli/2017-10-10/linea-ciclabile-da-piazza-darmi-al-polo-sportivo-retrostante-alla-stazione-olimpica-pinerolo-12737

A Pinerolo (To) stanno realizzando questa pista ciclabile cittadina.

L'articolo cita che a Pesaro, Treviglio, San Donato Milanese, Pistoia, 
Rovigo e Lignano è o sta per essere attuata.


Qualche mappatore nei comuni citati sopra ha già visionato o mappato 
tali piste? Se si mi piacerebbe un confronto.


Io attendo la fine dei lavori e se nessuno la traccia prima di me la 
riporto.


Ciao..

Gianluca

--
Gianluca Boero


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

[OSM-talk] OSM Contributors Outlook - The Pulse of OpenStreetMap Contributors

[Pierre Béland]

I published a Diary where I analyse the OSM Contributions, trying to have a 
different perspective on the data.  I briefly show the results of a Cohort 
analysis of the OSM contributors. These analysis are often used to compare the 
progression of various groups from day 1 of a particular event and analyse 
their behavior for a certain period. They help reveal trends in the data.  For 
OSM, this let observe the big peak of new entries which is followed by massive 
departs the next month. In fact, a majority of contributors do not participate 
more then one day. 
I also review the monthly statistics of Contributors and Contributions with 
contributors Profiles and show the heterogeneity between the vast majority of 
contributors that contribute minimally and at the other extent of the 
distribution, the minority that contribute massively to OSM. 

See https://www.openstreetmap.org/user/PierZen/diary/42470
 
Pierre 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Parco fluviale Po e Orba

[Andrea Albani]

Il nome non è corretto, ma le tue assunzioni secondo me si.

Comunque vedendo l'autore dell'oggetto non mi sorprendo.
Fredie è quello che ha mappato una quantità inverosimile di landuse lungo
tutto il corso del Po scopiazzando bellamente da Google maps (dicendo che
il source è Bing) e creando changeset monstre da 5000-6000 change l'uno.
Ha inoltre una vena artistica perchè ogni tanto abbellisce i boschi con un
natural=tree qui e uno là, così la mappa gli appare più bella da vedere.
E' quello che cambia i nomi delle cascine aggiungendo "ex" davanti perchè
gli sembra il modo migliore di dire che forse non sono abitate e ne
trasforma il landuse=farmyard in landuse=grassland.
Dimostra inoltre una predilezione per i leisure=garden privati: fa un'unico
poligono che unisce tutti i giardini attigui senza distinzione di confini
di proprietà... e potrei continuare.
Era già stato segnalato in lista, ha ricevuto commenti ai changeset che non
legge, ma ha continuato imperterrito.
Ogni tanto correggo quello che fa se ci capito sopra, ma riparare tutto
quello che ha fatto è un lavoro enorme. Per fortuna sembra abbia smesso la
sua attività in Italia 8 mesi fa penso in seguito all'attenzione che aveva
avuto in lista in un precedente thread.

Dopo questa personale premessa di inquadramento del nostro contributore
compulsivo la prima domanda che mi pongo è: da dove ha preso i dati  per
tracciare quel confine?

Secondariamente, visto il personaggio, non mi farei troppi scrupoli a
modificare come ritieni, o come ritiene la lista, quanto hai trovato.

Ciao

Il giorno 10 ottobre 2017 22:52, Dario Crespi  ha
scritto:

> Ciao,
>
> vedo che il Parco fluviale Po e Orba compare mappato a pezzetti, ciascuno
> con il nome "Parco fluviale Po e Orba (parte)": http://www.
> openstreetmap.org/search?query=parco%20fluviale%20po%
> 20e%20orba#map=14/45.0047/8.7390
>
> Credo non sia corretto, ma preferisco prima chiedere qui: non andrebbe
> messo tutto sotto un'unica relazione?
>
> Dario
>
> ___
> 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] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Federico Cortese]

2017-10-11 9:51 GMT+02:00 Alfredo Gattai :
>
> faccio una precisazione, forse superflua. Quando esiste un percorso che ha
> un nome ed un numero questi tag NON si mettono sulle singole way ma si crea
> la apposita relation. Quindi se per ipotesi esiste un percorso che ha il
> numero 111 e si chiama "Via della Transumanza" si crea una relazione con
>
> ref=111
> name=Via della Transumanza
>
> sulle singole way non devono essere ripetuti.
>

+1 Grazie Alfredo, hai fatto bene a precisare perchè dalla mia
risposta si poteva fraintendere.

Ciao,
Federico

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

Re: [Talk-it] tabelle accesso su ciclabili e ciclopedonali

[emmexx]

Segnalo questa pagina che chiarisce tutti i punti oscuri evidenziati da
Martin:

http://www.ciclistaurbano.net/problemi_obbligo_tutti_ciclisti_usare_piste_ciclabili_art_182_codice_strada.html

ciao
maxx

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

Re: [Talk-de] finde.cash! - name / operator

[Martin Koppenhoefer]

sent from a phone

> On 11. Oct 2017, at 09:04, Nils Vierus  wrote:
> 
> @Martin: Mit den VR Banken ist mir das noch nicht ganz transparent: benötigen 
> wir hier in einer Vorbelegung des Attributs [name] nun mehrere Bezeichnungen 
> oder genügt uns Volksbank, VR-Bank oder so ähnlich? (In [operator] wird dann 
> der konkrete lokale Institutsname eingetragen.)


evtl. macht es hier Sinn, den tag network zu verwenden für den Verband? 
https://de.m.wikipedia.org/wiki/Bundesverband_der_Deutschen_Volksbanken_und_Raiffeisenbanken


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

[Talk-cat] Fòrum TIG SIG = OPEN geodata

[Wladimir Szczerban]

Hola a todos

El 8 novembre de 2017 al MWC[1] será el Fòrum TIG SIG que tratará sobre
OPEN geodata. Creo que es una buena oportunidad para hablar sobre OSM y
para ver si podemos hacer
que organismos públicos pongan sus datos disponibles para poder usarlos en
OSM.

Ya que muchos de los asistentes son del mundo local ajuntaments, consell
comarcal, diputacions, gencat, etc. Podríamos preparar una carta tipo de
autorización de uso de datos para OSM, explicar lo fácil que es el proceso
de ceder los datos e intentar recolectar direcciones de correos de
responsables de la administración para enviarles la carta.

Ya luego se podría prepar una presentación evaluando los portales de
opendata de Catalunya y ver si se pueden usar en OSM o explicar los
beneficios de usar OSM en la administración se podría explicar el caso de
Ajuntament de Figueres (correo de Esther)

[1] http://osm.org/go/xUbR2mK4m?m=

-- 
Saludos,

Bolo
www.geoinquiets.cat
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Martin Koppenhoefer]

sent from a phone

> On 11. Oct 2017, at 09:51, Alfredo Gattai  wrote:
> 
> Quindi se per ipotesi esiste un percorso che ha il numero 111 e si chiama 
> "Via della Transumanza" si crea una relazione con
> 
> ref=111
> name=Via della Transumanza
> 
> sulle singole way non devono essere ripetuti.


questo ovviamente solo quando tutto il percorso si chiama così, altrimenti i 
nomi vanno sui way (il nome della relazione (insieme di vie e sentieri che 
costituiscono il percorso) è quello del tag name sulla relazione, il nome del 
singolo sentiero e della singola strada va sul way)

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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Alfredo Gattai]

Ciao,

faccio una precisazione, forse superflua. Quando esiste un percorso che ha
un nome ed un numero questi tag NON si mettono sulle singole way ma si crea
la apposita relation. Quindi se per ipotesi esiste un percorso che ha il
numero 111 e si chiama "Via della Transumanza" si crea una relazione con

ref=111
name=Via della Transumanza

sulle singole way non devono essere ripetuti.

Come ha precisato Federico, l'operator e' l'ente che ne ha la
responsibilita' di manutenzione quindi e' fondamentale che questa
informazione venga inserita se la si conosce con certezza. Il fatto che
abbia una segnaletica CAI non significa che il CAI sia l'operator. Molto
spesso il vero operator e' il Comune, la Provincia, la Regione, un parco od
una associazione. Tali informazioni sono tipicamente note in quelle regioni
dove c'e' una legge quadro sulla sentieristica ed catasto gestito tipo
Trentino, Piemonte, Liguria, etc.

Se non si conosce con certezza l'informazione meglio astenersi
dall'ipotizzare chi sia l'operator.

Per il resto guardati la wiki come ha suggerito Federico e se hai altre
domande siamo qua'. C'e' anche la talk dedicata indicata nella wiki.

Ciao
Alfredo







2017-10-11 0:01 GMT+02:00 :

> Chiedo dettagli su una controversia in atto per quanto riguarda
> l'assegnazione dei nomi sentieri CAI e della relazione percorso
> escursionistico
>
> Espressamente: è corretto indicare nel TAG NOME questa nomenclatura:
> [nomegestore] [nome/numero sentiero] [Provincia se il gestore è CAI] ?
> Qualcuno dice che il TAG NOME non va indicato: è giusto?
> Reputo che:
> Il nomegestore sia utile perché più gestori adottano stessi numerisentiero.
> Il numerosentiero serva per ovvie ragioni.
> La provincia (CAI) sia utile poiché CAI adotta stessi numeri per diverse
> provincie anche confinanti, dunque si conferirebbe una univocità ad un
> sentiero.
>
> Per la relazione "percorso escursionistico" è giusto indicare nel TAG NOME
> la stessa nomenclatura indicata per la linea sentiero di cui sopra?
>
> Grazie a tutti.
>
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Publication OpenData du cadastre

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE)]

Hello,

Tu sélectionnes  tous tes objets avec type :way puis tu demandes la  validation 
 des objets puis la réparation et hop JOSM ne râle plus

De : David Marchal [mailto:pene...@live.fr]
Envoyé : mercredi 11 octobre 2017 08:33
À : Discussions sur OSM en français 
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre


Bonjour.



Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les polygones 
des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ; apparemment, les 
bâtiments sont constitués d’une ligne dont le premier et le dernier point ont 
les mêmes coordonnées, mais ne sont pas le même point. Pour JOSM, le polygone 
n’est pas fermé.



Cordialement.


De : Vincent Privat >
Envoyé : mardi 3 octobre 2017 23:34
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre

Hello,
Quelques compléments d'info sur JOSM.
Le support du cadastre est disponible, il faut utiliser la toute dernière 
version stable (12921) de JOSM et la version 33690 du greffon cadastre-fr.
J'ai annoncé la nouvelle version du greffon il y a quelques jours sur la liste 
dev-fr, et on en a parlé aussi au dernier meeting toulousain, j'ai déjà corrigé 
quelques soucis de jeunesse suite aux tests préliminaires des mappeurs 
toulousains :)

Le greffon permet d'ouvrir les lots Edigéo via file/open, file/open location, 
ou en drag, soit de l'archive tar.bz2, soit du fichier .THF.
Les géométries sont automatiquement simplifiées pour éviter d'avoir des 
piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une 
limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives du 
cadastre (sauf dans les cas de bâtiments à cheval sur plusieurs planches).
Actuellement sont chargés le bâti, les limites administratives, les parcelles & 
sections, les adresses, la voirie, et diverses autres choses (puits, pylônes, 
cimetières, bâtiment de culte, etc.). Tout est sourcé avec le tag habituel 
"cadastre-fr ... DGFiP 2017 etc.".
Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que 
représentées par un nœud, et les choses qui sont bizarrement regroupées dans le 
cadastre telles que "terrains de sport et petits ruisseaux" (WTF?!), ou bien 
"parking, terrasse, surplomb", etc.
Pour les curieux la correspondance entre les données du cadastre et les tags 
OSM se fait ici:
https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37
[https://avatars1.githubusercontent.com/u/261431?v=4=400]

openstreetmap/josm-plugins
github.com
josm-plugins - Mirror of the JOSM plugin repository in Subversion



Les calques chargés ainsi dans JOSM sont flaggués "envoi dissuadé". C'est à 
dire: JOSM va vous crier dessus si vous essayez d'envoyer ces données vers OSM, 
pour sensibiliser tout le monde qu'il y a un gros travail de vérification & 
d'intégration à mener avant de faire ça. Si je vois qu'il y a des dérives et 
des imports massifs sans travail préalable, je basculerai rapidement en mode 
"envoi interdit", ce qui bloquera complètement l'envoi direct à partir de ces 
calques.

Il me manque à exploiter la date de dernière mise à jour (je pense à la mettre 
dans un tag source:date).

J'attends l'API Etalab avec impatience, ça permettra à JOSM de télécharger les 
données du cadastre pour une zone donnée (actuellement il faut connaître le 
numéro de planche du cadastre).

Si vous trouvez des bugs n'hésitez pas à me les remonter :)

A+
Vincent





Le 3 octobre 2017 à 14:47, Christian Quest 
> a écrit :
Oui, officiellement dispo depuis hier... :)

Les données brutes de la DGFiP sont au format EDIGEO, format peu courant mais 
ouvrable avec gdal (donc QGis).

Dans cette première livraison, Etalab propose une extraction des principales 
couches d'infos surfaciques remise au format geojson en WGS84: limites de 
communes, de section cadastrale, de parcelle, et l'emprise des bâtiments.

Des données sont téléchargeables par département et par communes pour les 
geojson et par département et feuille cadastrale pour l'EDIGEO.

Ces données seront mises à jour trimestriellement.


Les nouveautés à venir pour les contributeurs:

- la prochaine version de JOSM va pouvoir ouvrir directement les fichier EDIGEO 
de la DGFiP.
- l'extraction du bâti de 
cadastre.openstreetmap.fr deviennent en 
partie inutiles
- les script d'extraction d'adresses de 

Re: [Talk-de] finde.cash! - name / operator

[Nils Vierus]

Ich werte für Banken und Geldautomaten sowohl operator als auch name aus (in 
dieser Reihenfolge) und zeige dann das erste gefundene Attribut an (bei GA als 
„Operator“, bei Banken als „Name“). Banken werden aber prinzipiell nur 
angezeigt, wenn atm=yes getaggt ist (es ist ja eine Geldautomatenkarte).

Für das getrennte Tagging von Automaten in/bei Banken würde ich auf die 
Öffnungszeiten abstellen:
Da die Automaten häufig von der dazugehörigen Filiale getrennte Öffnungszeiten 
haben (in einem Foyer, SB-Center o.ä., das aber aus naheliegenden Gründen nicht 
mehr 24/7 geöffnet hat), würde ich sie in diesen Fällen als amenity=atm mit 
eigenem opening_hours mappen (dann gibt es in finde.cash zwei nebeneinander 
liegende Marker), wenn sich die GA allerdings innerhalb der Bankfiliale 
befinden und damit die gleiche Öffnungszeit haben, würde ich sie bei der Bank 
mit atm=yes mappen und sie würden die Öffnungszeiten der Bank „übernehmen“.

@Martin: Mit den VR Banken ist mir das noch nicht ganz transparent: benötigen 
wir hier in einer Vorbelegung des Attributs [name] nun mehrere Bezeichnungen 
oder genügt uns Volksbank, VR-Bank oder so ähnlich? (In [operator] wird dann 
der konkrete lokale Institutsname eingetragen.)

Gruß Nils



Am 10. Oktober 2017 um 16:30:51, Harald Hartmann 
(osm-talk...@haraldhartmann.de) schrieb:


>> On 9. Oct 2017, at 22:44, Martin Koppenhoefer  wrote:
>>
>> das wäre hier der Name der Filiale
>
> bei amenity=bank wäre es der Name der Filiale, bei Geldautomaten kann man 
> sehen, ob es überhaupt einen Namen gibt.
>

Danke für den Hinweis, den man genauer betrachten sollte:
der Geldautomat wird häufig ja gar nicht alleine/eigenständig, sondern
als atm=yes zusammen mit einer Bank erfasst ... und man bei dieser
Kombination die Werte für name und operator (und evtl. brand und
network) vielleicht anders/genauer setzt, als wenn man nur den
Geldautomaten taggt

@Nils: hast du zufällig bei dir einen germany-extrakt rumliegen und
könntest hierzu einfach mal ein paar statistiken entwerfen (nix
supertolles grafisches, einfach ein paar zahlen reichen [1]), z.B.
verhältnis amenity=bank ohne atm=yes, amenity=bank mit atm=yes und
amenity=atm
oder eine Auflistung und Anzahl von network und operator?

[1] z.B.
http://wiki.openstreetmap.org/wiki/User:Haribo/statistics/motorway#Vorbereitung



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

Re: [Talk-GB] Quarterly Project: Addresses and Postcodes

[Jez Nicholson]

Hi Robert,

You might be able to give the '1AA's special treatment as I believe they
are reserved for the local postal sorting office. So, BN1 1AA is the main
Brighton sorting office, however BN2 1AA is the now closed Hove Post Office.

Regards,
Jez
On Tue, 10 Oct 2017 at 19:09, Robert Whittaker (OSM lists) <
robert.whittaker+...@gmail.com> wrote:

> It doesn't seem to have been mentioned here yet, but this quarter's UK
> mapping project is to improve addresses and postcodes:
> https://osmuk.org/uncategorized/jump-in-to-our-quarterly-mapping-project/
>
> I've had a go at starting a wiki page for it at
>
> https://wiki.openstreetmap.org/wiki/UK_2017_Q4_Project:_Addresses_and_Postcodes
> which will hopefully contain some useful information. I'd encourage
> others to help improve it further.
>
> To coincide with the launch of the project I've also done a bit of
> development on my previous postcode analysis tools at
> http://robert.mathmos.net/osm/postcodes/ . You can now see stats of
> how many postcodes are mapped in each area, district and sector, as
> well as viewing potential errors (postcodes not found in Code-Point
> Open, or that are a long way from their centroid) to check/fix.
>
> As well as just generally increasing the number of addresses and
> postcodes in OSM, a couple of possible goals for the quarter would be
> to ensure we've map at least one postcode in each sector (only 615 to
> go), and to reduce the number of sectors with less than 5% of units
> present in OSM (currently 5562).
>
> I'd also like to draw your attention to the OSM/FHRS comparison
> excellent tool at http://gregrs.dev.openstreetmap.org/fhrs/ which is a
> great source of addresses/postcodes of food outlets to add in areas
> where some amenities are mapped but not individual houses.
>
> Robert.
>
> --
> Robert Whittaker
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Publication OpenData du cadastre

[David Marchal]

Bonjour.


Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les polygones 
des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ; apparemment, les 
bâtiments sont constitués d’une ligne dont le premier et le dernier point ont 
les mêmes coordonnées, mais ne sont pas le même point. Pour JOSM, le polygone 
n’est pas fermé.


Cordialement.



De : Vincent Privat 
Envoyé : mardi 3 octobre 2017 23:34
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre

Hello,
Quelques compléments d'info sur JOSM.
Le support du cadastre est disponible, il faut utiliser la toute dernière 
version stable (12921) de JOSM et la version 33690 du greffon cadastre-fr.
J'ai annoncé la nouvelle version du greffon il y a quelques jours sur la liste 
dev-fr, et on en a parlé aussi au dernier meeting toulousain, j'ai déjà corrigé 
quelques soucis de jeunesse suite aux tests préliminaires des mappeurs 
toulousains :)

Le greffon permet d'ouvrir les lots Edigéo via file/open, file/open location, 
ou en drag, soit de l'archive tar.bz2, soit du fichier .THF.
Les géométries sont automatiquement simplifiées pour éviter d'avoir des 
piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une 
limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives du 
cadastre (sauf dans les cas de bâtiments à cheval sur plusieurs planches).
Actuellement sont chargés le bâti, les limites administratives, les parcelles & 
sections, les adresses, la voirie, et diverses autres choses (puits, pylônes, 
cimetières, bâtiment de culte, etc.). Tout est sourcé avec le tag habituel 
"cadastre-fr ... DGFiP 2017 etc.".
Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que 
représentées par un nœud, et les choses qui sont bizarrement regroupées dans le 
cadastre telles que "terrains de sport et petits ruisseaux" (WTF?!), ou bien 
"parking, terrasse, surplomb", etc.
Pour les curieux la correspondance entre les données du cadastre et les tags 
OSM se fait ici:
https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37
[https://avatars1.githubusercontent.com/u/261431?v=4=400]

openstreetmap/josm-plugins
github.com
josm-plugins - Mirror of the JOSM plugin repository in Subversion



Les calques chargés ainsi dans JOSM sont flaggués "envoi dissuadé". C'est à 
dire: JOSM va vous crier dessus si vous essayez d'envoyer ces données vers OSM, 
pour sensibiliser tout le monde qu'il y a un gros travail de vérification & 
d'intégration à mener avant de faire ça. Si je vois qu'il y a des dérives et 
des imports massifs sans travail préalable, je basculerai rapidement en mode 
"envoi interdit", ce qui bloquera complètement l'envoi direct à partir de ces 
calques.

Il me manque à exploiter la date de dernière mise à jour (je pense à la mettre 
dans un tag source:date).

J'attends l'API Etalab avec impatience, ça permettra à JOSM de télécharger les 
données du cadastre pour une zone donnée (actuellement il faut connaître le 
numéro de planche du cadastre).

Si vous trouvez des bugs n'hésitez pas à me les remonter :)

A+
Vincent





Le 3 octobre 2017 à 14:47, Christian Quest 
> a écrit :
Oui, officiellement dispo depuis hier... :)

Les données brutes de la DGFiP sont au format EDIGEO, format peu courant mais 
ouvrable avec gdal (donc QGis).

Dans cette première livraison, Etalab propose une extraction des principales 
couches d'infos surfaciques remise au format geojson en WGS84: limites de 
communes, de section cadastrale, de parcelle, et l'emprise des bâtiments.

Des données sont téléchargeables par département et par communes pour les 
geojson et par département et feuille cadastrale pour l'EDIGEO.

Ces données seront mises à jour trimestriellement.


Les nouveautés à venir pour les contributeurs:

- la prochaine version de JOSM va pouvoir ouvrir directement les fichier EDIGEO 
de la DGFiP.
- l'extraction du bâti de 
cadastre.openstreetmap.fr deviennent en 
partie inutiles
- les script d'extraction d'adresses de 
cadastre.openstreetmap.fr et de BANO vont 
aussi pouvoir évoluer prochainement.

Il y a d'autres données provenant du cadastre qui seront bientôt disponibles:
- le PCI Image et  les localisants de parcelles
- l'historique des évolutions des parcelles (la parcelles XXX est séparée en 
YYY et ZZZ)


Les fichiers EDIGEO permettent bien plus que ce qu'on a pu faire jusqu'à 
maintenant. On a par exemple 

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

[Federico Cortese]

2017-10-11 8:19 GMT+02:00 Federico Cortese :
> 2017-10-11 0:01 GMT+02:00  :
>>
>> Espressamente: è corretto indicare nel TAG NOME questa nomenclatura: 
>> [nomegestore] [nome/numero sentiero] [Provincia se il gestore è CAI] ?
>
> [nomegestore] = operator

Aggiungo che se con [nomegestore] si intende il CAI, nel tag operator
invece si indica l'ente che ha la responsabilità di manutenere il
percorso.
Per maggiore approfondimento suggerisco la pagina wiki:
https://wiki.openstreetmap.org/wiki/CAI, dove è indicato anche come
compilare correttamente il campo name.

Ciao,
Federico

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