Re: [talk-cz] Springfield > OpenGeofiction?

[xkomc...@centrum.cz]

Ahoj,

Technicky určitě ano, OpenGeofiction používá ten samý stack jako OSM. 
Akorát: "Keep it real. No fantasy, science fiction, joke countries, 
etc." + "No copying trademarked maps". Takže nevím, jestli by to tam 
sedělo "ideologicky"...



Pokud do toho půjdeš, určitě si dopředu vyzkoušej nějakou editaci, ať 
jsi připraven na rozdílnosti (např. nutnost "rezervovat" si území, než 
na něm začneš mapovat - 
https://wiki.opengeofiction.net/wiki/index.php/OGF:Territories ). Pak už 
stačí mapu, co jsi posílal, "převést" na WM(T)S, přidat jako podklad do 
editoru a můžeš začít obkreslovat.


Jirka

On 05. 12. 19 0:27, Ladislav Nesnera wrote:

Ahoj

V Otevřenkách bychom rádi z didaktických důvodů, a trochu pro 
odlehčení, vybudovali fiktivní obec Springfield (ano, se Simpsonů a s 
jejich reáliemi. Zda nám to projde licenčně se ještě uvidí). Na té 
bychom chtěli prezentovat možnosti svobodného SW ve veřejné správě a 
samozřejmě spousta obecního dění se odehrává v prostoru..


Je tu někdo, kdo používá OpenGeofiction ? 
Rád bych věděl, zda myšlenka přenést tento svět 
 (reálie 
, "3D 
" 
:D) do OpenGeofiction je realizovatelný nápad


  *  samozřejmě pokud by byla odpověď kladná, určitě uvítáme pomoc,
ale to dost předbíhám

A jinak všem pohodový advent

;?


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

[OSM-talk-fr] [BANO v2] : intégration d'adresses par relation associatedStreet

[Vincent de Château-Thierry]

Bonjour,
suite à différentes remarques et suggestions, je viens de publier une 
modification de fonctionnement pour l'intégration des adresses sous 
forme de relations dans les pages 
https://dev.cadastre.openstreetmap.fr/fantoir/
Désormais, un clic sur un lien 'Relation' cherchera, dans l'ordre, à 
utiliser une relation associatedStreet existante portant sur la même 
rue, et sinon à créer cette relation si aucune n'a été trouvée.
Pour une relation nouvelle, l'outil essaie maintenant de trouver les 
ways pertinents, ayant leur place comme membres 'street' dans la relation.


Pour ceux qui préfèrent intégrer les adresses sous forme de points, 
normalement la fonctionnalité est inchangée.


Tout ça n'a été testé que par moi, donc vos retours bienvenus si vous 
constatez des comportements bizarres au niveau de l'outil.


merci
vincent

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

Re: [OSM-talk-fr] SNT, éducation nationale / Nombre maximum d'appareils connectés à un compte

[Vincent Bergeot]

Le 04/12/2019 à 15:58, marc marc a écrit :

Bonjour,


Le 4 déc. 2019 à 13:57, Vincent Bergeot
Savez vous si il y a un maximum d'appareils connectables à un compte unique OSM 
?

Aucune limite connue mais en cas de vandalisme tu ne saurai jamais qui c'est.
Un compte ÉcoleAbcClasse1N1 a20 me semble bien préférable


ok pour la crainte du vandalisme, mais demander à créer 10 comptes par 
classe pour chaque classe de seconde de lycée cela me semble :


1- difficile pour les profs (blabla+compte1@ac- ... et cela 10 fois cela 
va demander une formation à part entière avant même de commencer


2- démesuré car beaucoup de ces élèves vont faire une contribution (au 
mieux), auront entendu parler d'osm et leur lien avec osm s’arrêtera là 
(ce qui est déjà énorme !!!)


Donc l'idée "défendue" et mise dans la lettre aux DANE (délégation 
académique aux numériques éducatifs de France) c'est d'avoir un compte 
classe pour le temps du cours, avec profil précisant #snt, le lycée, la 
classe éventuellement, avec changement de mot de passe à l'issue de la 
séance. Si il y a du vandalisme à ce moment là, ok mais cela fait 
néanmoins l'objet d'un changeset, c'est plus "facile" à détecter.


Si ensuite, sur les 500 000 élèves tous les ans, 1/1 (rêvons 1/1000) 
deviennent contributeurs en se créant leur compte perso, c'est super ! 
Et là on peut s'attendre à aussi peu de vandalisme que par ailleurs !


à plus

--
Vincent Bergeot


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

[OSM-ja] 12月28日長崎市にてOSM交流会開催されます。

[ikiya]

Ikiyaです。
12月28日（土）長崎市にてOSM交流会が開催されます。
OpenStreetMapの基本や関連する話題、長崎の地理的特性について夕刻お食事・飲みながら語り合う交流会です。

「OpenStreetMap交流会 in Nagasaki」
【日時】2019年12月28日（土）18:30 -20:30（予定）
【開催場所】浜町周辺の居酒屋でゆるーく開催します。
【会費】4000円程度を想定
（OSM交流会イベント内容・参加申し込み）
https://www.facebook.com/events/434127190613384/
///

また交流会前にプレイベントととして、OSM体験街歩き（フィールドワーク体験会）を行います。こちらは15：30-17:30　長崎市 湊公園 集合です。
気軽にご参加ください！
（OSM体験街歩きイベント参加申し込み）
https://www.facebook.com/events/578808965995760/
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-it] operator reale

[Martin Koppenhoefer]

sent from a phone

> On 4. Dec 2019, at 16:06, Volker Schmidt  wrote:
> 
> Il mio punto era di mettere nel campo "operatore" l'operatore effettivo.


chi è l’operatore effettivo? Infine sarebbero le persone individuali che fanno 
“il lavoro”? L’operatore effettivo non è quello che ha vinto la gara ed è 
responsabile che il lavoro viene fatto?
Al micro livello ci saranno sempre condivisioni, per esempio in un museo c’è la 
gestione artistica/curatela, quella amministrativa/economica, poi ci sarà chi 
pulisce i bagni, chi la guardaroba e chi i biglietti, chi taglia il prato in 
giardino, ecc ecc. Vogliamo tenere traccia di tutti questi appalti?

Se nel caso dell’isola ecologica mettessimo la coop soc. come operator, come 
metteremmo l’Aprica Spa., la quale “gestisce ufficialmente”?

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

[talk-cz] Springfield > OpenGeofiction?

[Ladislav Nesnera]

Ahoj

V Otevřenkách bychom rádi z didaktických důvodů, a trochu pro odlehčení,
vybudovali fiktivní obec Springfield (ano, se Simpsonů a s jejich
reáliemi. Zda nám to projde licenčně se ještě uvidí). Na té bychom
chtěli prezentovat možnosti svobodného SW ve veřejné správě a samozřejmě
spousta obecního dění se odehrává v prostoru..

Je tu někdo, kdo používá OpenGeofiction ?
Rád bych věděl, zda myšlenka přenést tento svět
 (reálie
, "3D
"
:D) do OpenGeofiction je realizovatelný nápad

  *  samozřejmě pokud by byla odpověď kladná, určitě uvítáme pomoc, ale
to dost předbíhám

A jinak všem pohodový advent

;?



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

Re: [OSM-talk] Proposal process Wikipage - Adding note about the use of seperators for values

[Steve Doerr]

On 04/12/2019 18:42, Yves wrote:
The semicolon is one information out of many, I'm not sure we should 
add this in the already long 'proposal process' page.


Note that there is a slightly cryptic reference in 
https://wiki.openstreetmap.org/wiki/Proposal_process#Compatibility_with_established_practices:


> Syntactic conventions for new tags

> There are some conventions about naming keys and values. Following 
them will help mappers to estimate the meaning of your tags without 
reading the documentation. Using a semicolon

> should be considered especially carefully.

--

Steve


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

Re: [Talk-it] Incroci e highway=*_link

[Lorenzo Mastrogiacomi]

Il giorno mer, 04/12/2019 alle 17.37 +0100, Federico Cortese ha
scritto:
> On Wed, Dec 4, 2019 at 11:31 AM Andrea Albani 
> wrote:
> > In questa situazione io userei questi tag solo sui rami/rampe degli
> > incroci senza rotatorie.
> 
> Sì, la situazione appare abbastanza confusa, motivo per cui a me
> nonsembrano utili i tag *_link, sarei più propenso all'uso solo
> nellesituazioni evidenti dove ci sono rami/rampe.
> Ciao,Federico

Anche io direi solo sulle connessioni con le strade veloci, non nei
semplici spartitraffico di incroci/rotatorie.
Qui c'è una discussione recente su tagging:
https://lists.openstreetmap.org/pipermail/tagging/2018-December/041500.html

Lorenzo

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

Re: [OSM-talk-fr] dégradation notable d'OSM

[Guillaume Rischard]

Salut tous,

J’ai mis un message à l’utilisateur, qui ne pourra pas continuer à éditer sans 
confirmer l’avoir lu :

https://www.openstreetmap.org/user_blocks/3312 


Pour la suggestion de pouvoir freiner un éditeur, un gros message bien visible 
comme ça suffit  en général - l’immense majorité des gens ne se rendent pas 
compte des problèmes. Sinon, on a la possibilité de bloquer quelques jours, et, 
pour les personnes qui ne comprennent vraiment pas, de façon permanente.

Sur une tangente, il y a 
https://github.com/openstreetmap/openstreetmap-website/issues/2342 
 qui 
propose de limiter le nombre d’éditions par personne et par jour. La discussion 
parle aussi des imports, et essaie de définir une unité d’édition.

Guillaume


> On 4 Dec 2019, at 15:17, DURUPT Celine (EXT CONCRETIO) 
>  wrote:
> 
> J'ai déjà utilisé landuse=traffic_island (exemple : 
> https://www.openstreetmap.org/way/476606647 ) mais d'après le wiki 
> (https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dtraffic_island) il faut 
> (peut-être ?) maintenant utiliser : area:highway=traffic_island
> 
> Céline
> 
> -Message d'origine-
> De : Florimond Berthoux [mailto:florimond.berth...@gmail.com] 
> Envoyé : mardi 3 décembre 2019 10:40
> À : Discussions sur OSM en français
> Objet : Re: [OSM-talk-fr] dégradation notable d'OSM
> 
> +1 Tous les îlots ne sont pas là pour "calmer" (ralentir) le trafic,
> bien au contraire, les îlots de ronds points sont fait pour séparer le
> trafic et les insérer avec un angle de giration sympathique permettant
> une bonne allure.
> Il ne faut pas utiliser traffic_calming=island pour cela !
> 
> Le lun. 2 déc. 2019 à 21:01, Stéphane Péneau
>  a écrit :
>> 
>> Bizarre, Osmand ne m'a jamais fait ce genre d'erreur, ou alors je ne
>> m'en suis pas rendu compte.
>> 
>> En tout cas traffic_calming ne me semble pas vraiment approprié si on se
>> réfère à son sens premier. La séparation à l'entrée/sortie d'un
>> giratoire n'est pas là pour ralentir le trafic.
>> 
>> Stf
>> 
>> Le 02/12/2019 à 18:50, Dominique Rousseau a écrit :
>>> Le Fri, Nov 29, 2019 at 09:46:14PM +0100, osm.sanspourr...@spamgourmet.com 
>>> [osm.sanspourr...@spamgourmet.com] a écrit:
>>> [...]
> - Suppression des pattes d'oie à l'arrivée sur un rond point
 Tu veux dire les haricots séparant les voies ? Si ça se trouve c'est
 parce qu'il en a marre qu'OSMAND ne compte pas bien les sorties !
 On peut aussi modéliser avec des traffic_calming=island
 .
>>> Ah, merci !
>>> J'ai dejà eu l'occasion de créer des ways séparés pour représenter des
>>> choses comme ça, et je trouvais ça plutot moche.
>>> Maintenant je saurais comment les faire :)
>>> 
>>> 
>> 
>> 
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Florimond Berthoux
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> ---
> Ce message et toutes les pièces jointes sont établis à l'intention exclusive 
> de ses destinataires et sont confidentiels. L'intégrité de ce message n'étant 
> pas assurée sur Internet, la SNCF ne peut être tenue responsable des 
> altérations qui pourraient se produire sur son contenu. Toute publication, 
> utilisation, reproduction, ou diffusion, même partielle, non autorisée 
> préalablement par la SNCF, est strictement interdite. Si vous n'êtes pas le 
> destinataire de ce message, merci d'en avertir immédiatement l'expéditeur et 
> de le détruire.
> ---
> This message and any attachments are intended solely for the addressees and 
> are confidential. SNCF may not be held responsible for their contents whose 
> accuracy and completeness cannot be guaranteed over the Internet. 
> Unauthorized use, disclosure, distribution, copying, or any part thereof is 
> strictly prohibited. If you are not the intended recipient of this message, 
> please notify the sender immediately and delete it. 
> ___
> 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] Incroci e highway=*_link

[Martin Koppenhoefer]

sent from a phone

> On 4. Dec 2019, at 16:08, Volker Schmidt  wrote:
> 
> Ma come posso sapere io, contributore di dati, sapere che cosa hanno deciso i 
> consumatori di dati.


appunto, e secondo lo scopo e le idee del consumatore, i default saranno 
diversi.


> O ci sono default definit da qualche parte o non ci sono default.


non ci sono ;-)
Ci sono le supposizioni che dipendono dall’esperienza (tipicamente locale) dei 
mappatori. Per esempio se aggiungi surface=asphalt ad un highway=primary in 
Italia, la maggior parte dei mappatori lo vedrebbe ridondante.

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

Re: [Talk-it] Incroci e highway=*_link

[Lorenzo Mastrogiacomi]

Il giorno mer, 04/12/2019 alle 11.30 +0100, Andrea Albani ha scritto:
> A riguardo delle rotatorie la wiki riporta questa frase che sembra
> sconfessare l'uso dei *_link se non in specifici casi:
> 
> 
> Links are also used in roundabout designs that physically separate a
> specific turn from the main roundabout. 
> 
> Ma quali sarebbero le uscite fisicamente separate dalla rotatoria che
> non sono specifiche ? Se si intendono i rami oneway di accesso,
> allora bisogna mettere a posto il validatore di JOSM. Non riesco ad
> immaginarmi altri casi.
> 
> 

Penso che parla dei collegamenti laterali che bypassano la rotatoria
come in questo caso:
https://www.openstreetmap.org/#map=18/44.06400/12.54070





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

Re: [Talk-it] Incroci e highway=*_link

[Lorenzo Mastrogiacomi]

Il giorno mer, 04/12/2019 alle 12.02 +0100, Martin Koppenhoefer ha
scritto:
> Am Mi., 4. Dez. 2019 um 11:19 Uhr schrieb Martin Koppenhoefer <
> dieterdre...@gmail.com>:
> > per me è piùttosto indifferente, se il tagging è "completo" (i link
> > al solito sono considerati di default oneway=yes e lanes=1 se non
> > sbaglio, mentre le strade oneway=no e lanes=2). 
> > 
> 
> ho appena visto che qualcuno ha cambiato il wiki (al meno
> parzialmente) e adesso dice che motorway_link non implica oneway=yes
> e dice anche di mettere oneway=no quando è a due direzioni ;)
> Per me è una conferma di mettere sempre sia lanes che oneway nel caso
> di un _link perché i cosìdetti default le cambiano a volontà...
> 
> Ciao
> Martin
> 

Il dubbio comunque è solo su motorway_link perché le motorway sono
indicate come oneway=yes di default.
Per gli altri gradi direi che non ci sono grossi dubbi sul fatto che di
default sono a doppio senso.


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

Re: [OSM-talk] Proposal process Wikipage - Adding note about the use of seperators for values

[Martin Koppenhoefer]

sent from a phone

>> On 4. Dec 2019, at 20:43, Sören Reinecke via talk  
>> wrote:
> 
> Short notes should do the trick. User are free to click on ghe hyperlinks to 
> get detailed information. We can do that for all information.


regarding multiple values, this is not generally agreed to be undesired, 
particularly not in all cases. While it could probably create problems for 
“feature tags” there are also some properties where multiple values are 
generally accepted, e.g. values for brand, or several people in subject, 
architect or other similar situations.

There is already ample information on this page about the topic: 
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator

IMHO it is not helpful adding more secondary information for all eventualities 
on the page which describes the proposal process. If there isn’t already, it 
could be stated that people are encouraged to confront their ideas first with 
the community (e.g. tagging ML, local ML, forum etc.) rather than spending a 
lot of time with preparing a proposal in isolation, just to find out later that 
there is already an alternative way to represent what they are after.

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

Re: [Talk-gb-westmidlands] December - Christmas curry

[Eike Ritter via Talk-gb-westmidlands]

Daer all,

> 
> In what is now becoming a bit of a tradition, we discussed going for
> curry for our December mappa mercia meeting. If in agreement I suggest
> we stick to the same place as previous years (Manzils Restaurant, Digbeth).
> 
> First Thursday of the month would make it 5th December. Shall we say to
> meet at 7:30?
> 
Sounds fine to me - see you there.

Best wishes,

Eike
> Best regards,
> *Rob*
> 
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
> 




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

Re: [OSM-talk] Proposal process Wikipage - Adding note about the use of seperators for values

[Sören Reinecke via talk]

> The semicolon is one information out of many.Short notes should do the trick. User are free to click on ghe hyperlinks to get detailed information. We can do that for all information.CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [OSM-talk] Proposal process Wikipage - Adding note about the use of seperators for valuesFrom: Yves To: Sören Reinecke ,Sören Reinecke via talk ,Mateusz Konieczny CC: Talk The semicolon is one information out of many, I'm not sure we should add this in the already long 'proposal process' page.Especially considering that semicolons are discouraged but we do use them, this is not ideal for clarity. Le 4 décembre 2019 17:35:57 GMT+01:00, "Sören Reinecke via talk"  a écrit :
I expected a note about that it is not wanted to have tags with semicolon seperated values. I expected this inclusive a hyperlink in the "Before creating a proposal" of the page https://wiki.openstreetmap.org/wiki/Proposal_processQuestion: It is allowed to alter that page to add more helpful information?CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [OSM-talk] Proposal process Wikipage - Adding note about the use of seperators for valuesFrom: Mateusz Konieczny To: CC: Talk 
  

  
  
What is your question?What kind of note you expected and where?4 Dec 2019, 10:37 by talk@openstreetmap.org:Hey all,someone pinpointed me to the wiki at https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator and I looked at https://wiki.openstreetmap.org/wiki/Proposal%20process and wonder why I cannot find a note about that.CheersSören Reinecke alias Valor Naram___talk mailing listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk  

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

Re: [Talk-gb-westmidlands] December - Christmas curry

[Andy Robinson]

Happy Christmas all, enjoy your curry.

 

Cheers

Andy

 

From: Brian Prangle [mailto:bpran...@gmail.com] 
Sent: 04 December 2019 19:18
To: Rob Nickerson; talk-gb-westmidlands
Subject: Re: [Talk-gb-westmidlands] December - Christmas curry

 

Gosh it come around quickly! See you there

 

On Wed, 4 Dec 2019 at 18:34, Rob Nickerson  wrote:

Hi all,

 

Just a reminder that this is tomorrow (Manzils Restaurant, Digbeth - Thursday, 
5th December meet at 7:30).

 

Hope to see you there.

 

Rob

 

On Sat, 23 Nov 2019, 21:42 Rob Nickerson,  wrote:

Great. Anyone else able to make it?


Rob

 

 

On Fri, 22 Nov 2019 at 15:14, Brian Prangle  wrote:

Works for me

 

On Thu, Nov 21, 2019 at 10:05 PM Rob Nickerson  
wrote:

Hi all,

 

In what is now becoming a bit of a tradition, we discussed going for curry for 
our December mappa mercia meeting. If in agreement I suggest we stick to the 
same place as previous years (Manzils Restaurant, Digbeth).

 

First Thursday of the month would make it 5th December. Shall we say to meet at 
7:30?

 

Best regards,

Rob

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

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

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

Re: [Talk-gb-westmidlands] December - Christmas curry

[Brian Prangle]

Gosh it come around quickly! See you there

On Wed, 4 Dec 2019 at 18:34, Rob Nickerson 
wrote:

> Hi all,
>
> Just a reminder that this is tomorrow (Manzils Restaurant, Digbeth
> - Thursday, 5th December meet at 7:30).
>
> Hope to see you there.
>
> Rob
>
> On Sat, 23 Nov 2019, 21:42 Rob Nickerson, 
> wrote:
>
>> Great. Anyone else able to make it?
>> *Rob*
>>
>>
>> On Fri, 22 Nov 2019 at 15:14, Brian Prangle 
>> wrote:
>>
>>> Works for me
>>>
>>> On Thu, Nov 21, 2019 at 10:05 PM Rob Nickerson <
>>> rob.j.nicker...@gmail.com> wrote:
>>>
 Hi all,

 In what is now becoming a bit of a tradition, we discussed going for
 curry for our December mappa mercia meeting. If in agreement I suggest we
 stick to the same place as previous years (Manzils Restaurant, Digbeth).

 First Thursday of the month would make it 5th December. Shall we say to
 meet at 7:30?

 Best regards,
 *Rob*
 ___
 Talk-gb-westmidlands mailing list
 Talk-gb-westmidlands@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

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

Re: [OSM-talk] Proposal process Wikipage - Adding note about the use of seperators for values

[Yves]

The semicolon is one information out of many, I'm not sure we should add this 
in the already long 'proposal process' page.
Especially considering that semicolons are discouraged but we do use them, this 
is not ideal for clarity. 

Le 4 décembre 2019 17:35:57 GMT+01:00, "Sören Reinecke via talk" 
 a écrit :
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Cartes les plus avancées

[Julien Coupey]

Bonjour

Vu les échanges lors du dernier State of the Map France, il semblerait 
que la ville de Montrouge occupe à elle toute seule les 10 premières 
places du classement. ;-)


À +
Julien (déjà sorti)

On 04/12/2019 19:31, Xavier BIZOT wrote:

Bonjour à toutes et à tous

Quelles sont selon vous les villes dont la carte est le plus avancée une 
sorte de TOP 10 ?


Je vous remercie

Amicalement

Xavier

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



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

Re: [Talk-gb-westmidlands] December - Christmas curry

[Rob Nickerson]

Hi all,

Just a reminder that this is tomorrow (Manzils Restaurant, Digbeth
- Thursday, 5th December meet at 7:30).

Hope to see you there.

Rob

On Sat, 23 Nov 2019, 21:42 Rob Nickerson,  wrote:

> Great. Anyone else able to make it?
> *Rob*
>
>
> On Fri, 22 Nov 2019 at 15:14, Brian Prangle 
> wrote:
>
>> Works for me
>>
>> On Thu, Nov 21, 2019 at 10:05 PM Rob Nickerson 
>> wrote:
>>
>>> Hi all,
>>>
>>> In what is now becoming a bit of a tradition, we discussed going for
>>> curry for our December mappa mercia meeting. If in agreement I suggest we
>>> stick to the same place as previous years (Manzils Restaurant, Digbeth).
>>>
>>> First Thursday of the month would make it 5th December. Shall we say to
>>> meet at 7:30?
>>>
>>> Best regards,
>>> *Rob*
>>> ___
>>> Talk-gb-westmidlands mailing list
>>> Talk-gb-westmidlands@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>>>
>>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

[OSM-talk-fr] Cartes les plus avancées

[Xavier BIZOT]

Bonjour à toutes et à tous

Quelles sont selon vous les villes dont la carte est le plus avancée une
sorte de TOP 10 ?

Je vous remercie

Amicalement

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

Re: [Talk-it] Incroci e highway=*_link

[Federico Cortese]

On Wed, Dec 4, 2019 at 4:08 PM Volker Schmidt  wrote:
>
> So che il consumatore dei dati decide.
> Ma come posso sapere io, contributore di dati, sapere che cosa hanno deciso i 
> consumatori di dati. O ci sono default definit da qualche parte o non ci sono 
> default.
> E' un problema che abbiamo in tanti casi in OSM.
>

Vero, nel caso in questione se tra highway=tertiary e tertiary_link ci
fosse la chiara differenza dei valori di default indicata da Martin
(oneway e lanes) avrebbero forse un senso, ma allo stato dell'arte
appaiono piuttosto inutili.

Ciao,
Federico

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

Re: [Talk-it] Incroci e highway=*_link

[Federico Cortese]

On Wed, Dec 4, 2019 at 11:31 AM Andrea Albani  wrote:
>
> In questa situazione io userei questi tag solo sui rami/rampe degli incroci 
> senza rotatorie.
>

Sì, la situazione appare abbastanza confusa, motivo per cui a me non
sembrano utili i tag *_link, sarei più propenso all'uso solo nelle
situazioni evidenti dove ci sono rami/rampe.

Ciao,
Federico

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

Re: [OSM-talk] Proposal process Wikipage - Adding note about the use of seperators for values

[Sören Reinecke via talk]

I expected a note about that it is not wanted to have tags with semicolon seperated values. I expected this inclusive a hyperlink in the "Before creating a proposal" of the page https://wiki.openstreetmap.org/wiki/Proposal_processQuestion: It is allowed to alter that page to add more helpful information?CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [OSM-talk] Proposal process Wikipage - Adding note about the use of seperators for valuesFrom: Mateusz Konieczny To: CC: Talk 
  
  
What is your question?What kind of note you expected and where?4 Dec 2019, 10:37 by talk@openstreetmap.org:Hey all,someone pinpointed me to the wiki at https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator and I looked at https://wiki.openstreetmap.org/wiki/Proposal%20process and wonder why I cannot find a note about that.CheersSören Reinecke alias Valor Naram___talk mailing listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk  

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

Re: [Talk-it] operator reale

[demon_box]

boh io per ora ho risolto così:

official_operator=Aprica S.p.a.
operator=Il Gelso Cooperativa Sociale Onlus

--enrico




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

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

Re: [OSM-talk] Proposal process Wikipage - Adding note about the use of seperators for values

[Mateusz Konieczny]

What is your question?

What kind of note you expected and where?

4 Dec 2019, 10:37 by talk@openstreetmap.org:

> Hey all,
>
> someone pinpointed me to the wiki at 
> https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator and I looked 
> at https://wiki.openstreetmap.org/wiki/Proposal%20process and wonder why I 
> cannot find a note about that.
>
> Cheers
>
> Sören Reinecke alias Valor Naram
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Incroci e highway=*_link

[Volker Schmidt]

So che il consumatore dei dati decide.
Ma come posso sapere io, contributore di dati, sapere che cosa hanno deciso
i consumatori di dati. O ci sono default definit da qualche parte o non ci
sono default.
E' un problema che abbiamo in tanti casi in OSM.

On Wed, 4 Dec 2019 at 15:44, Martin Koppenhoefer 
wrote:

> Am Mi., 4. Dez. 2019 um 13:29 Uhr schrieb Volker Schmidt <
> vosc...@gmail.com>:
>
>> Questi default, sono definiti da qualche parte formalmente?
>>
>>>
>
> probabilmente non solo da una parte, ma in più punti e forse dicono anche
> il contrario ;-)
> Il vero default è quello che un utilizzatore dei dati presume quando il
> dato non c'è.
> Come mappatore, non è consigliabile pensare ci siano dei default fissi,
> anche se sono scritte da qualche parte.
>
> 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] operator reale

[Volker Schmidt]

Il mio punto era di mettere nel campo "operatore" l'operatore effettivo.

On Wed, 4 Dec 2019 at 15:50, Martin Koppenhoefer 
wrote:

> Am Mi., 4. Dez. 2019 um 14:59 Uhr schrieb Lorenzo Beltrami <
> lorenzo.b...@gmail.com>:
>
>> Si potrebbe tenere in considerazione di usare la chiave brand?
>>
>> Esempio:
>> brand=Aprica +
>> operator= Cooperativa Sociale Il Gelso
>>
>> Non è propriamente un franchise, però potrebbe avere senso...
>>
>> Per la questione dei subappalti ricorsivi si perderebbero comunque tutti
>> quelli intermedi (brand = appaltante, operator = ultimo livello, quello che
>> fisicamente sta sul posto).
>>
>
>
> non è un brand in questo caso. L'operatore è la persona / ente che
> gestisce una cosa. In questo caso direi è chi è responsabile per la
> gestione / a chi è stata affidata, e questo sarebbe per me Aprica. Se non
> funziona la gestione, sarà Aprica a doversi giustificare. Loro poi potranno
> a loro volta rivolgersi al "Gelso".
>
> 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: [OSM-talk-fr] SNT, éducation nationale / Nombre maximum d'appareils connectés à un compte

[marc marc]

Bonjour,

> Le 4 déc. 2019 à 13:57, Vincent Bergeot

> Savez vous si il y a un maximum d'appareils connectables à un compte unique 
> OSM ?

Aucune limite connue mais en cas de vandalisme tu ne saurai jamais qui c'est.
Un compte ÉcoleAbcClasse1N1 a20 me semble bien préférable 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] operator reale

[Martin Koppenhoefer]

Am Mi., 4. Dez. 2019 um 14:59 Uhr schrieb Lorenzo Beltrami <
lorenzo.b...@gmail.com>:

> Si potrebbe tenere in considerazione di usare la chiave brand?
>
> Esempio:
> brand=Aprica +
> operator= Cooperativa Sociale Il Gelso
>
> Non è propriamente un franchise, però potrebbe avere senso...
>
> Per la questione dei subappalti ricorsivi si perderebbero comunque tutti
> quelli intermedi (brand = appaltante, operator = ultimo livello, quello che
> fisicamente sta sul posto).
>


non è un brand in questo caso. L'operatore è la persona / ente che gestisce
una cosa. In questo caso direi è chi è responsabile per la gestione / a chi
è stata affidata, e questo sarebbe per me Aprica. Se non funziona la
gestione, sarà Aprica a doversi giustificare. Loro poi potranno a loro
volta rivolgersi al "Gelso".

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

Re: [Talk-it] Incroci e highway=*_link

[Martin Koppenhoefer]

Am Mi., 4. Dez. 2019 um 13:29 Uhr schrieb Volker Schmidt :

> Questi default, sono definiti da qualche parte formalmente?
>
>>

probabilmente non solo da una parte, ma in più punti e forse dicono anche
il contrario ;-)
Il vero default è quello che un utilizzatore dei dati presume quando il
dato non c'è.
Come mappatore, non è consigliabile pensare ci siano dei default fissi,
anche se sono scritte da qualche parte.

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

Re: [OpenStreetMap Serbia] Editor za srpski

[Predrag Supurovic]

U međuvremenu je mnogo toga na unosu srpskih naziva na Kosovu i Metohiji 
urađeno.


U prinipcu svi nazivi mesta do nivoa sela i zaselaka koji su mogli biti 
uneti na srpskom uneti su. Veliki broj toponima takođe.


U nekim mestima sa većinskim srpskim stanovništvom su u dobroj meri i 
ulicama uneti nazivi na srpskom jeziku.


Problem na koji nailazimo je nedostatak podataka o tačnim nazivima 
najpre za ulice. Ovo se naročito tiče ulica kojima su nazivi ne 
preslovljeni nego promenjeni u šiptarske tako da ko ne poznaje stvari na 
terenu ne može da zna kakav je ispravan naziv na srpskom.


Za to su neophodni ljudi koji tamo žive ili makar dobro poznaju pojedina 
mesta. Pokušao sam u nekoliko navrata da kontaktiram neke lokalne medije 
pa i SPC nastojeći da nađem nekoga sa KiM ko bi mogao da pomogne oko 
unošewa naziva na srpskom ali nisam nikad dobio ni odgovore a kamoli 
neki kontakt.


Nakon ovih izmena napravljen je i namenski rendering server koji 
renderuje OSM mapu na srpskom jeziku tako da je na njoj i područje 
Kosova i Metohije sada prikazano na srpskom jeziku u onoj meri u kojoj 
su podaci uneti. Tu se lako vidi šta je urađeno a šta tek treba da se uradi.


Mapa je na https://www.osmsrbija.iz.rs/map/#9/42.6208/20.7848

Ova mapa se može koristiti i kao podloga u lokalizovanom ID editoru 
http://id.osmsrbija.iz.rs tako da je unos izmena na srpskom olakšano.


Editor je takođe dorađen pa je i u njemu lakše videti šta treba da se 
sređuje. 
http://editor.osmsrbija.iz.rs/?dataset=kim=on=on


Naročito treba proveriti pre editovanja istoriju izmena na objektima 
koji nemaju sprski ili g aimaju uneto pogrešno. Ako se izistorije vidi 
da su Šiptari namerno skrnavili unose onda u opis izmene obavezno treba 
staviti napomenu da se radi o ispravci vandalizacije.


Vrlo je važno da se izmene unose u name:sr tag. name tag ne treba dirati 
jer imamo zabranu da ga popunjavamo srpskim jezikom.


Za više detalja o tome kako treba unositi izmene pogledajte 
https://forum.openstreetmap.org/viewtopic.php?id=66973


Vrlo koristan je i Sophos servis. Mislim da je Branko napravio skript za 
nejga koji olakšava unos naziva na srpskom. Evo primera 
https://tinyurl.com/r38dmuf



Inače su svi alati predviđeni da se koriste za unos naziva na srpskom 
jeziku za sva područja gde živi srpsko stanovništvo. Crna Gora je na 
primer skoro 100% mapirana na srpskom jeziku.


On 18.12.2017. 13:11, Milos Glisovic wrote:

Peđa potpuno se slažem.
Za početak granice, nazivi oblasti i većih mesta i što je moguće više 
podataka o prostoru gde žive Srbi.
Juče sam pričao o značaju mapa sa kolegama koji su živeli na KiM do 
1999. (tehnička lica i jedan profesor srpskog jezika). Zajedničko 
mišljenje je prihvatiti i prevesti nove šiptarske nazive ulica i 
ostaviti napomenu kako su se zvale do 1999. (Kako?) Posebno bolno i 
teško je šta raditi sa nazivima mesta (ne tako malih) koja su 
šiptarizovana  Uroševac - Ferizaj, Srbica - Skenderaj, Obilić - 
Kastriot, Suva Reka- Theranda, Istok - Burim, Kosovska Kamenica - 
Dardan, Devet Jugovića - Bardhosh , Leposavić - Albana
Kada bi mogli da organizujemo neku radionicu sa ljudima koji žive na KiM 
o problemima naziva i  da im zatim objasnimo osnove oko mapiranja. Da 
oni sami mogu da rade  a mi bi pomogli. Možda tehnički fakultet?
Arsić je dekan. Njega poznajemo. Ovo bi svakao trebalo do podrži 
zajednica ali i država.


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

Re: [OSM-talk-fr] dégradation notable d'OSM

[DURUPT Celine (EXT CONCRETIO)]

J'ai déjà utilisé landuse=traffic_island (exemple : 
https://www.openstreetmap.org/way/476606647 ) mais d'après le wiki 
(https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dtraffic_island) il faut 
(peut-être ?) maintenant utiliser : area:highway=traffic_island

Céline

-Message d'origine-
De : Florimond Berthoux [mailto:florimond.berth...@gmail.com] 
Envoyé : mardi 3 décembre 2019 10:40
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] dégradation notable d'OSM

+1 Tous les îlots ne sont pas là pour "calmer" (ralentir) le trafic,
bien au contraire, les îlots de ronds points sont fait pour séparer le
trafic et les insérer avec un angle de giration sympathique permettant
une bonne allure.
Il ne faut pas utiliser traffic_calming=island pour cela !

Le lun. 2 déc. 2019 à 21:01, Stéphane Péneau
 a écrit :
>
> Bizarre, Osmand ne m'a jamais fait ce genre d'erreur, ou alors je ne
> m'en suis pas rendu compte.
>
> En tout cas traffic_calming ne me semble pas vraiment approprié si on se
> réfère à son sens premier. La séparation à l'entrée/sortie d'un
> giratoire n'est pas là pour ralentir le trafic.
>
> Stf
>
> Le 02/12/2019 à 18:50, Dominique Rousseau a écrit :
> > Le Fri, Nov 29, 2019 at 09:46:14PM +0100, osm.sanspourr...@spamgourmet.com 
> > [osm.sanspourr...@spamgourmet.com] a écrit:
> > [...]
> >>> - Suppression des pattes d'oie à l'arrivée sur un rond point
> >> Tu veux dire les haricots séparant les voies ? Si ça se trouve c'est
> >> parce qu'il en a marre qu'OSMAND ne compte pas bien les sorties !
> >> On peut aussi modéliser avec des traffic_calming=island
> >> .
> > Ah, merci !
> > J'ai dejà eu l'occasion de créer des ways séparés pour représenter des
> > choses comme ça, et je trouvais ça plutot moche.
> > Maintenant je saurais comment les faire :)
> >
> >
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



-- 
Florimond Berthoux

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] operator reale

[Lorenzo Beltrami]

Il giorno mer 4 dic 2019 alle ore 12:59 demon_box 
ha scritto:

> ciao caso concreto
> isola ecologica gestita ufficialmente da Aprica Spa come tante altre in
> zona
> ke xò subappalta alla Cooperativa Sociale Il Gelso...
>
> come gestire correttamente le 2 informazioni?
>
> grazie
>
> --enrico
>

Si potrebbe tenere in considerazione di usare la chiave brand?

Esempio:
brand=Aprica +
operator= Cooperativa Sociale Il Gelso

Non è propriamente un franchise, però potrebbe avere senso...

Per la questione dei subappalti ricorsivi si perderebbero comunque tutti
quelli intermedi (brand = appaltante, operator = ultimo livello, quello che
fisicamente sta sul posto).

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

Re: [Talk-it] operator reale

[Martin Koppenhoefer]

Am Mi., 4. Dez. 2019 um 12:59 Uhr schrieb demon_box :

> ciao caso concreto
> isola ecologica gestita ufficialmente da Aprica Spa come tante altre in
> zona
> ke xò subappalta alla Cooperativa Sociale Il Gelso...
>
> come gestire correttamente le 2 informazioni?



si potrebbe inventare un nuovo tag per il subappaltatore.

tipo
operator=Aprica Spa.
contractor=Cooperativa Sociale Il Gelso

La domanda che sorge, come facciamo con i subappaltatori dei subappaltatori
dei subappaltatori dei subappaltatori dei subappaltatori dei subappaltatori
dei subappaltatori dei subappaltatori?

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

Re: [OpenStreetMap Serbia] Prvo okupljanje domaće OSM zajednice

[Predrag Supurovic]

Evo najave i na sajtu Daljine.rs

https://daljine.rs/open-street-map-srbija-organizuje-svoje-prvo-okupljanje-7-decembra/

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

Re: [OSM-talk-fr] Vidéo sur l'historique et les projections des cartes

[Xavier Cremaschi]

Le 02/12/2019 à 09:59, Stéphane Péneau a écrit :

Hello,

Une petite vidéo sur l'histoire des cartes :

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

Stf


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



Très intéressant comme petit récapitulatif, merci !


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

[OSM-talk-fr] SNT, éducation nationale / Nombre maximum d'appareils connectés à un compte

[Vincent Bergeot]

Bonjour,

je suis désolé je crois que la réponse à déjà été donné mais je ne 
retrouve pas.


Savez vous si il y a un maximum d'appareils connectables à un compte 
unique OSM ?


En pratique, connecter tous les ordi d'une salle informatique (15-20), à 
un seul compte classe OSM.


Par avance merci de vos lumières !

VincentB


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

Re: [Talk-it] operator reale

[Volker Schmidt]

Quello che mi interessa come utente finale dell'informazione: a chi devo
rivolgermi se devo chiamarli.

On Wed, 4 Dec 2019, 12:59 demon_box,  wrote:

> ciao caso concreto
> isola ecologica gestita ufficialmente da Aprica Spa come tante altre in
> zona
> ke xò subappalta alla Cooperativa Sociale Il Gelso...
>
> come gestire correttamente le 2 informazioni?
>
> grazie
>
> --enrico
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Incroci e highway=*_link

[Volker Schmidt]

On Wed, 4 Dec 2019, 11:28 Martin Koppenhoefer, 
wrote:

>  (i link al solito sono considerati di default oneway=yes e lanes=1  non
> sbaglio, mentre le strade oneway=no e lanes=2).
>
Questi default, sono definiti da qualche parte formalmente?

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

[Talk-it] operator reale

[demon_box]

ciao caso concreto
isola ecologica gestita ufficialmente da Aprica Spa come tante altre in zona
ke xò subappalta alla Cooperativa Sociale Il Gelso...

come gestire correttamente le 2 informazioni?

grazie

--enrico 




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

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

Re: [Talk-it] Incroci e highway=*_link

[Martin Koppenhoefer]

Am Mi., 4. Dez. 2019 um 11:19 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

> per me è piùttosto indifferente, se il tagging è "completo" (i link al
> solito sono considerati di default oneway=yes e lanes=1 se non sbaglio,
> mentre le strade oneway=no e lanes=2).
>


ho appena visto che qualcuno ha cambiato il wiki (al meno parzialmente) e
adesso dice che motorway_link non implica oneway=yes e dice anche di
mettere oneway=no quando è a due direzioni ;)
Per me è una conferma di mettere sempre sia lanes che oneway nel caso di un
_link perché i cosìdetti default le cambiano a volontà...

Ciao
Martin


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

Re: [Talk-it] Mappare una scuola due

[Martin Koppenhoefer]

Am Mi., 4. Dez. 2019 um 07:04 Uhr schrieb Francesco Ansanelli <
franci...@gmail.com>:

> penso che non sia paragonabile, perché il mise non è il gestore dei
> benzinai, non è il ref ufficiale ma soltanto una chiave estranea, mentre il
> ref delle scuole è ufficiale e quello di chi gestisce le scuole. Forse mi
> sbaglio e anche nel caso delle scuole non è il ref principale?
>
>>
>> Si tratta di codice "meccanografico", assegnato dal MIUR per quanto ne
> so, in quanto dovrebbe comparire anche nei loro bollettini.
> Mi domando se abbia un significato al di fuori del MIUR... Es. nel ref
> potrei voler mettere un numero assegnato dal comune: media 1, media 2 ecc
> ecc...
>


non ho mai visto altri codici rispetto quelli del MIUR per le scuole, ma
non escludo che potrebbero forse esistere da qualche parte. Solitamente si
usano i nomi e eventualmente i codici MIUR.



> Al momento ho usato alt name per questi casi.
>


si, anche questo è possibile, potrebbe essere anche loc_ref per esempio.



> Martin che ne dici se contiamo i ref delle scuole con e senza MIUR finale
> e facciamo vincere la maggioranza?
>


certo. Se hai già riscontrato esempi di "ref" alternativi ("media 1" ecc.),
potrebbe comunque avere senso utilizzare questi per "ref" e utilizzare
"ref:miur" per il codice meccanografico.

Il vantaggio è che è esplicito, lo svantaggio che probabilmente "ref" è un
campo che ti fanno vedere la maggiorparte degli editori (iD ecc.), mentre
"ref:miur" deve essere supportato esplicitamente (visto che si tratta di un
tag che avrebbe senso solo in Italia, le probabilità di essere supportato
da editori generici è meno alta). Attualmente, a livello globale, ci sono
combinazioni note per "ref" e "ref:UAI" (id francese), ref:edubase (Department
for Education EduBase URN) e ref:bag (BAG reference number for properties).
Quest'ultimo probabilmente non è riferito alle scuola ma all'edificio.
Considerato questo, direi di suggerire l'utilizzo di "ref:MIUR" (se siamo
d'accordo converrebbe inoltre creare una pagina (al meno) nel wiki inglese,
che contiene come minimo una descrizione nel template, per far capire agli
altri il significato).

Tra ref:miur e ref:MIUR sarebbe forse meglio utilizzare la versione
"ref:MIUR" in quanto sembra l'ortografia ufficiale.

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

Re: [OSM-talk-fr] dégradation notable d'OSM

[lenny.libre]

Le 03/12/2019 à 21:15, osm.sanspourr...@spamgourmet.com a écrit :


Stéphane et David, vu que vous êtes ceux qui avez le plus investi dans 
la vérification des modifications et que toutes les remarques sur les 
modifications sont restées sans réponse :


http://resultmaps.neis-one.org/osm-discussion-comments?uid=2322305, je 
crois que vous êtes les mieux placés pour demander un blocage au DWG 
le temps que cette personne réponde à vos interrogations.


Je vois aussi parmi les métriques : Osmose issues 
: Level 1=96, Level 
2=999, Level 3=1870.


Oui près de 100 erreurs de niveau 1.

une remarque concernant uniquement le nombre d'anomalies Osmose : il me 
semble qu'il ne faudrait pas les prendre comme référence pour 
l'utilisateur, car, en modifiant un élément, on récupère ses anomalies 
(j'ajoute le nom à un arrêt de bus et je récupère l'anomalie comme quoi 
il n'est pas rattaché à une ligne de bus) parfois on récupère l'anomalie 
créée après coup (je crée un chemin, sur l'avant-dernier nœud un autre 
contributeur découpe le chemin et supprime le dernier tronçon qui le 
rattaché à un autre chemin, le contributeur reçoit une anomalie de 
"manque sans issue" sur le chemin et moi sur le nœud) ...


cordialement

leni

Sinon effectivement j'ai compris pourquoi OSMand déconnait : il ne 
passe pas par où passent OSRM, GraphHooper ou Bibi : il préfère 
doubler la distance que de prendre un raccourci par une route moins 
importante. Donc c'est une question de poids de certains éléments pour 
le calcul du trajet et non un mauvais comptage des sorties.


N. B. : Stéphane en fait je vois que tu le suis (subis !) depuis un 
moment, quant au bout d'une "certain temps" le contributeur ne répond 
pas et continue ses mauvaises pratiques, ça ne sert à rien de 
continuer sur le même mode il faut essayer un autre canal.


Jean-Yvon

Le 02/12/2019 à 21:09, David Crochet - david.croc...@free.fr a écrit :

Bonjour

Le 29/11/2019 à 21:46, osm.sanspourr...@spamgourmet.com a écrit :
Je pense naïvement que si c'était si mauvais on s'en serait aperçu 
plus tôt. mais pas sûr du tout.



C'est achavi qui m'a donné " l'alerte " car je surveille une zone, et 
il vient seulement d'y contribuer et mal, et c'est en regardant 
l'historique que j'ai vu qu'il cartographier mal depuis un moment.


Cordialement



___
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] Incroci e highway=*_link

[Andrea Albani]

Ciao,

non mi è mai stato molto chiaro cosa aggiunge una tag *_link al "panorama"
dei possibili valori di una highway.
Mi sembra valida la regola generale riportata nella wiki inglese, ovvero un
*_link si applica quando hai una diramazione verso una strada di classe
diversa.
Viene poi aggiunto che il valore da usare dipende da cosa si connette a
questa diramazione: se la destinazione ha una classe uguale o inferiore a
quella di provenienza si usa il _link della classe di provenienza,
viceversa quello della classe di destinazione. Es. da una primary verso
tertiary uso primary_link, mentre se vado verso una motorway uso
motorway_link come ben riassunto nella tabella [1]

Secondo questa logica la rotatoria che hai citato dovrebbe quindi avere i
rami di connessione delle 3 secondary marcati come highway=secondary e la
SP79, che è una tertiary, marcata nella due way di raccordo con
secondary_link ma quest'ultimo approccio sembra non piacere al
validatore di JOSM che segnala la situazione con un warning.
A riguardo delle rotatorie la wiki riporta questa frase che sembra
sconfessare l'uso dei *_link se non in specifici casi:

Links are also used in roundabout designs that physically separate a
specific turn from the main roundabout.

Ma quali sarebbero le uscite fisicamente separate dalla rotatoria che non
sono specifiche ? Se si intendono i rami oneway di accesso, allora bisogna
mettere a posto il validatore di JOSM. Non riesco ad immaginarmi altri casi.

In questa situazione io userei questi tag solo sui rami/rampe degli incroci
senza rotatorie.

Ciao

[1]
https://wiki.openstreetmap.org/wiki/File:This_table_highlights_how_you_connect_different_types_of_highway,_based_on_the_type_of_the_highway._.png


Il giorno mer 4 dic 2019 alle ore 09:44 Federico Cortese <
cortese...@gmail.com> ha scritto:

> Buogiorno a tutti,
> in seguito ad un confronto con un amico, ci siamo chiesti come sia
> meglio mappare gli incroci a raso tra strade tertiary, secondary o
> primary (es. https://www.openstreetmap.org/way/268705795), cioè se in
> questi casi sia opportuno o meno usare gli highway=tertiary_link e
> secondary_link.
> Stesso quesito relativamente alle rotatorie (es.
> https://www.openstreetmap.org/way/23614209).
> Io ricordavo vecchie discussioni per cui si riteneva opportuno usare i
> link solo nel caso delle rampe di collegamento o simili, ma non trovo
> più nulla in merito.
> Voi cosa ne pensate?
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Incroci e highway=*_link

[Martin Koppenhoefer]

Am Mi., 4. Dez. 2019 um 09:44 Uhr schrieb Federico Cortese <
cortese...@gmail.com>:

> Buogiorno a tutti,
> in seguito ad un confronto con un amico, ci siamo chiesti come sia
> meglio mappare gli incroci a raso tra strade tertiary, secondary o
> primary (es. https://www.openstreetmap.org/way/268705795), cioè se in
> questi casi sia opportuno o meno usare gli highway=tertiary_link e
> secondary_link.
> Stesso quesito relativamente alle rotatorie (es.
> https://www.openstreetmap.org/way/23614209).
> Io ricordavo vecchie discussioni per cui si riteneva opportuno usare i
> link solo nel caso delle rampe di collegamento o simili, ma non trovo
> più nulla in merito.
> Voi cosa ne pensate?



per me è piùttosto indifferente, se il tagging è "completo" (i link al
solito sono considerati di default oneway=yes e lanes=1 se non sbaglio,
mentre le strade oneway=no e lanes=2). Quindi secondo la scelta del valore
highway potrebbero essere richiesti più o meno tag (se uno si vuole
affidare ai "default", cosa non è sempre consigliabile in generale, visto
che lavoriamo generalmente con dati potenzialmente "incompleti", e si perde
la distinzione tra non mappato e non messo esplicitamente perché
considerato default).

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

Re: [Talk-it] Mappare marciapiedi stretti

[Martin Koppenhoefer]

Am Mi., 4. Dez. 2019 um 09:58 Uhr schrieb Volker Schmidt :

>
>
> On Wed, 4 Dec 2019 at 01:51, Alessandro Sarretta <
> alessandro.sarre...@gmail.com> wrote:
>
>> Per complicare le cose, ci possono essere casi in cui c'è un cordolo tra
>> un marciapiede e una pista ciclabile (es.
>> https://www.mapillary.com/map/im/G1IAo_4MG5Vfyr-4Az6BOA). Si mappa
>> comunque come barrier=kerb?
>>
>
> Per ulteriormente complicare le cose un "cordolo" secondo Wikipedia
>   è quello che in inglese si
> chiama "kerb" (GB English) o "curb" (US English).
> 
>


si, la parola "cordolo" può avere più significati, e non tutti sono i
"kerb" (per esempio l'uso architettonico, in tedesco "Ringanker", inglese
"circular beam" o "ring beam"). Nell'esempio di Ale, confermo quanto
scritto da Volker che si tratta di un retaining_wall (se le altezze sono
diverse) oppure di un "wall".


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

[OSM-talk] Proposal process Wikipage - Adding note about the use of seperators for values

[Sören Reinecke via talk]

Hey all,

someone pinpointed me to the wiki at 
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator and I looked at 
https://wiki.openstreetmap.org/wiki/Proposal%20process and wonder why I cannot 
find a note about that.

Cheers

Sören Reinecke alias Valor Naram
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Mappare marciapiedi stretti

[Volker Schmidt]

On Wed, 4 Dec 2019 at 01:51, Alessandro Sarretta <
alessandro.sarre...@gmail.com> wrote:

> Per complicare le cose, ci possono essere casi in cui c'è un cordolo tra
> un marciapiede e una pista ciclabile (es.
> https://www.mapillary.com/map/im/G1IAo_4MG5Vfyr-4Az6BOA). Si mappa
> comunque come barrier=kerb? In questo caso sarebbe corretto mappare le
> altezze da entrambi i "lati" del kerb con height:left=* e height:right=*?
>

Per ulteriormente complicare le cose un "cordolo" secondo Wikipedia
  è quello che in inglese si
chiama "kerb"
(GB English) o "curb" (US English).

Confermato anche dalle traduzioni Wikipedia in tedesco e francese.
Il tuo esempio per me è
(a) estremamente pericoloso e da eliminare o alzare
(b) probabilmente un mur(ett)o in OSM-speak: barrier=wall, hight=0.4
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Incroci e highway=*_link

[Federico Cortese]

Buogiorno a tutti,
in seguito ad un confronto con un amico, ci siamo chiesti come sia
meglio mappare gli incroci a raso tra strade tertiary, secondary o
primary (es. https://www.openstreetmap.org/way/268705795), cioè se in
questi casi sia opportuno o meno usare gli highway=tertiary_link e
secondary_link.
Stesso quesito relativamente alle rotatorie (es.
https://www.openstreetmap.org/way/23614209).
Io ricordavo vecchie discussioni per cui si riteneva opportuno usare i
link solo nel caso delle rampe di collegamento o simili, ma non trovo
più nulla in merito.
Voi cosa ne pensate?

Ciao,
Federico

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