Re: [OSM-talk-fr] erreur Overpass turbo

[David Crochet]

Le 09/11/2015 13:08, Philippe Verdy a écrit :

Si tu veux que tes mails
arrivent sans que tu changes ton adresse mail de souscription,  vérifie
tes paramètres SMTP pour l'envoi du courrier pour utiliser le serveur
SMTP de la poste quand tu écrits ici sous ton adresse mail de la poste.


Que neni, il utilise un DKIM-Signature. Donc c'est Gmail le problème.

Cordialement
--
David Crochet

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

Re: [OSM-talk-fr] Problème de nommage de rue

[Jérôme Seigneuret]

>
>
> Dans les manuels de littérature, c'est le nom complet qui est mentionné et
> le lien  avec la commune semble digne d'être indiqué.
> De bonnes raisons pour éviter l'abréviation .
>
>
Le choix dans OSM est clair de toute façon. Pas d’abréviation dans le name
sinon il y a le tag short_name
 pour cela.
Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] La mappa di OSM ha un nuovo schema colori

[Paolo Monegato]

Il 09/11/2015 13:05, Martin Koppenhoefer ha scritto:


2015-11-09 12:30 GMT+01:00 Paolo Monegato >:


- è bidimensionale (non è mica un plastico... il 3d lo fai con
qualche trucchetto grafico),



in realtà si tratta di una sorta di 3D (c'è anche la possibiltà di 
usare il trucchetto grafico in mancanza di dati), oppure al meno un 
2,5D ;-)
Associando delle altezze a dei punti, infine si ottiene una sorta di 
3D (x, y, z, dove z è contenuto per lo più in "ele"(tag) e 
"height"(tag)). Ovviamente non è adatto a rappresentare qualsiasi 
forma, per esempio per modellare questo è inadatto: 
http://tedytravel.com/wp-content/uploads/2015/06/London-Eye-3.jpg
Chiaramente non è inadatto ad un vero sistema 3D (alla fine è com'è 
stato sviluppato: in 3D dentro un computer), ma se lo vedi in OSM su 
F4 (una mappa, che generalmente è molto bella per ciò che facciamo in 
3D in OSM) ti rendi conto: 
http://demo.f4map.com/#lat=51.5040593=-0.1202126=18=53.881=36.096
Si potrebbe creare una rappresentazione migliore anche di questa 
ruota, ma sarebbe cmq. senza senso, perché aggirando il vero problema 
(mancaza di veri punti 3D e di un sistema specializzato in 3D) si 
dovrebbe fare tanti "hacks" molto discutibili (senza poi arrivare ad 
un vero buon punto).


Ciao,
Martin


Intendevo dire che come per la carta classica puoi dare un'idea 
dell'elevazione usando l'ombreggiatura così in OSM la tridimensionalità 
la fai usando la potenzialità del mezzo. Ma alla fine lo schermo è 
comunque piatto ed al lato pratico si tratta comunque di un qualcosa di 
bidimensionale.


ciao
Paolo M

ps: ovviamente conosco già F4 ;-)
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Problème de nommage de rue

[Ch. Rogel]

De : "Ludovic Hirlimann" 
Date : 9 nov. 2015 
11:17:35Sujet : Re: [OSM-talk-fr] Problème 
de nommage de rueje n'ai pas de problème avec Jean 
Jacques LEFRANC dans mon exemple. J'ai plus des problèmes avec rue/avenue et 
avec la partie manquante "de pompignan" , comment choisir entre rue et ave ? (j 
pense prendre le de pompugnan car présent dans le cadastre.Dans 
les manuels de littérature, c'est le nom complet qui est mentionné et le lien___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[dHuy Pierre]

Il y aussi start_date=C11 ou ~C11 ou même mid C11 pour le milieu du siècle qui 
correspond très bien plutôt que d'inventer un nouveau tag. 


 Le Lundi 9 novembre 2015 11h21, Philippe Verdy  a 
écrit :
   

 tu peux proposer "historic:century=11" si la classification par époque ou 
civilisation est difficile (d'ailleurs elle varie selon les pays ou cultures, 
ce qui est documenté est difficile à standardiser et faire accepter partout).le 
"start_date=*" est plutôt réservé à noter des dates précises (avec un format 
compatible ISO 8601 contenant au minimum une année complète), mais le XIe 
siècle n'est pas assez précis on ne peut pas non plus mettre 
"start_date=1001-1100" (format incompatible posant problème), start_date=1001 
(oui, le XIe siècle commence l'année suivant l'an mil) ou start_date=1050 
(milieu du siècle) serait au contraire trop précis (rien n'indique que c'est en 
fait une estimation à plus ou mois 50 ans près).
Le 9 novembre 2015 11:07, Jérôme Seigneuret  a écrit :

Bonjour, en faisant un fix sur le nom d'une église je me retrouve à 
avoir:Église ST Barthélémy XIième siècle que je corrige en Église 
Saint-Barthélémy-de-Baillarguet
Mon problème est d'ajouter l'information lié au XI ème siècle> période du moyen 
age central + précision sur le siècle
Ducoup je regarde du coté des tags 
http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilizationhistoric:period=
start_date=

Je me rend compte que rien n'est précisé sur les siècles tel que l'on a 
l'habitude de l'utilisé d'une part et que les grandes périodes de notre 
civilisation ne sont pas détaillé:
préhistoire et protohistoire c'est OK   
   - historic:civilization=prehistoric 
   - historic:civilization=protohistoric 

Reste les périodes après JC et les périodes spécifique à des régions
moyen-age :vie ‑xve
haut Moyen Âge = : vie ‑ xe siècleMoyen Âge central : xie ‑ xiiie siècleMoyen 
Âge tardif : xive ‑ xve siècle

époque moderne :
Époque moderne antérieure :1492 – 1792
époque contemporaine :

Époque moderne I : 1792 – 1920Époque moderne II : 1920 à nos jours


Bonne journéeJérôme

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




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


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

Re: [OSM-talk-fr] erreur Overpass turbo

[Philippe Verdy]

Non c'est la poste qui n'a pas validé dans son enregistrement DNS l'adresse
IP de tous ses serveurs SMTP sortants pu qui n'a pas o stable les
extensions s nécessaires sur tous ses serveurs. Gmail diagnostique que
cette adresse n'est pas authentifiée correctement. Cependant ce n'est pas e
cas du mail direct que tu viens de m'envoyer et dont la source est
authentifiée. La Poste n'utilise sans doute pas les mêmes serveurs sortants
selon que tu écrits à la liste OSM hébergée aux USA ou directement à un
côté personnel comme le mien.

Je voulais juste t'en informer car cela peut limiter l'audience attendue
des messages que tu postes à la liste et il y a de nombreux inscrits ici
avec Gmail, qui n'ont même pas vu que tes messages finissaient dans les
spams. Et ce problème touche certainement d'autres utilisateurs de la poste
qui ont du mal à recevoir certains courriers ou se plaignent de n'avoir
aucune réponse quand ces messages sont filtres indépendamment des auteurs
ou des contenus.
Le 9 nov. 2015 13:28, "David Crochet"  a écrit :

> Le 09/11/2015 13:08, Philippe Verdy a écrit :
>
>> Si tu veux que tes mails
>> arrivent sans que tu changes ton adresse mail de souscription,  vérifie
>> tes paramètres SMTP pour l'envoi du courrier pour utiliser le serveur
>> SMTP de la poste quand tu écrits ici sous ton adresse mail de la poste.
>>
>
> Que neni, il utilise un DKIM-Signature. Donc c'est Gmail le problème.
>
> Cordialement
> --
> David Crochet
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de traces GPS et conversion en chemins

[pepilepi...@ovh.fr]

Le 09/11/2015 15:32, Greg a écrit :
> Pour résumer, on va dire que la communauté est très frileuse
> concernant les imports car la donnée est rarement directement
> utilisable, il faut toujours retravailler. Dans le cas des traces GPX,
> c'est améliorer et intégrer le tracé qui est souhaité (ajouter des
> points là où il faut, les supprimer dans les sections droites,
> fusionner les intersections avec d'autres chemins...).
>
> Donc une trace GPX, c'est un outil de base, à utiliser avec l'imagerie
> aérienne et le cadastre pour croiser les sources.
>
> Et le cadastre n'est pas non plus intégralement dans OSM pour les
> mêmes raisons : pas d'import brut, mais de l'intégration manuelle pour
> garantir une qualité des données plutôt que la quantité.

C'est clair, merci.

JP


>
>
>
> 2015-11-08 23:09 GMT+01:00  >:
>
> Pour le cadastre, sous JOSM, il y a un greffon qui te permet
> d'afficher le cadastre en fond de plan.
> Vérifie le calage par rapport à des éléments existants dans OSM ou
> des orthophotographies.
>
> Sur le côté "aider un nouveau", c'est toi qui va nous aider ;-).
>
> Et on est toujours nouveau sur certains sujets.
> Cette liste permet même de se poser des questions sur des sujets
> dont on ignorait même l'existence ! Et de progresser sur des
> sujets que l'on pensait bien connaître.
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [Talk-us] Proposal: Sunset ref=* on ways in, favor of relations

[Richard Welty]

On 11/9/15 9:39 AM, Kevin Kenny wrote:
>
> In the issue on Github, you remark:
> "I'm contemplating closing this. As above, there are currently serious
> data issues in the US that prevent route relations from being used for
> rendering shields. If someone wants to take up the data quality issue,
> I could leave it open or re-open in the future, but unless it changes,
> I just can't see any way to make use of the route relations."
>
> That gives a horribly bleak outlook. I'm sure I'm misunderstanding
> what you say there, but it comes across as saying that the problem is
> forever unfixable, and that the hard work people have put in so far
> into generating route relations is all for naught, either because it
> remains incomplete or because the data model of route relations is
> fundamentally incompatible with shield rendering.
>
there's a chicken and egg problem here. you need mappers to work to fix
up route relations but it's hard to get motivated unless something visibly
happens with them.

this is the strategy i would use if i were able to contribute any time
(which
is unlikely for the next several months):

1) update the stylesheets for the proof-of-concept; they need to be
based on the current carto sheets going forward (if i remember correctly,
the proof-of-concept is pre-carto.)

2) bring up a map based on this up on a US chapter website, clearly
stating that its a demo/proof of concept for US shield rendering

3) make the needs/requirements for growing out the shield rendering
well known to the community. issues that require some care would include

a) svg files for shield types that are currently not represented (mostly
obscure county route signage)

b) the mapping files for shield->route (again, mostly county routes as
far as i know.)

the result will be that US based mappers will have a place they can go
look to see the results of their work. this, i think, would be a pretty
powerful motivator, and it doesn't require any action on the part of
the maintainers of the map on openstreetmap.org

it might be that the shield based rendering sticks on the US map
and never makes it to the international map, and that would be ok.

the key thing, i think, is that mappers have little motivation to work
on route relations if they don't actually get used by anything. show
them something and they might get interested again.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




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

Re: [OSM-talk-fr] Extractions du cadastre indisponibles

[Gaël Simon]

Bonjour,
Une source de simplification supplémentaire pourrait être de supprimer les 
points "alignés" (à moins de 20 cm ?). Ça pourrait éviter de surcharger la base 
avec des points inutiles, générés souvent aux limites de parcelle. 

Gaël


Le 6 nov. 2015 à 23:32, Tyndare  a écrit :

> Le 6 novembre 2015 22:37, David Crochet  a écrit :
> Le 06/11/2015 21:59, Tyndare a écrit :
>> 
>>  - merge (M) des nœuds proches (20 cm)
> 
> 
> En gros :
> 
> si un point déjà existant dans la base OSM se trouve à moins de x cm d'un
> point de l'extraction de la base cadastre, alors c'est le même.
> c'est ca ?

En fait non, il n'y a aucun lien avec la base OSM, c'est juste une
simplification du fichier extrait du cadastre, qui contient souvent
des points beaucoup trop proches les uns des autres pour que sa vaille
la peine de les distinguer.

> 
>>  - join (J) des nœuds au chemin proche (20 cm)
> 
> si un point déjà existant dans la base OSM se trouve à moins de x cm d'un
> chemin de l'extraction de la base cadastre, alors ajoute ce point au chemin,
> comme cela la prochaine fois, ça fera simplement un "merge".
> j'ai bien compris ?

Non, il ne s'agit toujours pas de merge avec les données de la base OSM.
Le merge est un sujet bien plus compliqué qui est traité ici:
- https://github.com/jecor/bati-fusion
ou là:
- https://github.com/sebastien-bugzilla/BatiOsm

Ici je ne parle toujours que d'extraction brute des données du
cadastre, rien de changé par rapport a avant.

> 
>>  - simplify (Shift-Y) des chemins avec un threshold=0.2
> 
> en d'autres termes ?

Je fais juste référence à la fonction JOSM de simplification des
chemins, comme expliqué sur le Wiki d'import semi automatique du bâti:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents

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

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

Re: [OSM-talk-fr] Import de traces GPS et conversion en chemins

[Greg]

Pour résumer, on va dire que la communauté est très frileuse concernant les
imports car la donnée est rarement directement utilisable, il faut toujours
retravailler. Dans le cas des traces GPX, c'est améliorer et intégrer le
tracé qui est souhaité (ajouter des points là où il faut, les supprimer
dans les sections droites, fusionner les intersections avec d'autres
chemins...).

Donc une trace GPX, c'est un outil de base, à utiliser avec l'imagerie
aérienne et le cadastre pour croiser les sources.

Et le cadastre n'est pas non plus intégralement dans OSM pour les mêmes
raisons : pas d'import brut, mais de l'intégration manuelle pour garantir
une qualité des données plutôt que la quantité.



2015-11-08 23:09 GMT+01:00 :

> Pour le cadastre, sous JOSM, il y a un greffon qui te permet d'afficher le
> cadastre en fond de plan.
> Vérifie le calage par rapport à des éléments existants dans OSM ou des
> orthophotographies.
>
> Sur le côté "aider un nouveau", c'est toi qui va nous aider ;-).
>
> Et on est toujours nouveau sur certains sujets.
> Cette liste permet même de se poser des questions sur des sujets dont on
> ignorait même l'existence ! Et de progresser sur des sujets que l'on
> pensait bien connaître.
>
> Jean-Yvon
>
> ___
> 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-br] Digest Talk-br, volume 86, assunto 9

[Helio Cesar Tomio]

Apenas para conhecimento geral:
O editor iD não está permitindo mais a exclusão de vias que pertencem a
relações.
Vc pode mover nós ou excluir, mas a via não.
Achei bom, pq evitam os problemas que aconteciam com este editor.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-ie] Sheet Request 26/9

[Donal Diamond]

Uploaded all 3 sheets in set:

http://mapwarper.net/maps?field=title=IRL-GSGS-3906-26-09_warped=0

D

On 9 November 2015 at 09:38, Mark Tully  wrote:

> Could I please get the following sheets uploaded:
>
>- 26/9 NW
>- 26/9 SW
>
> Thanks,
> Mark
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-cz] Špatně vložené rozcestníky (old.openstreetmap.cz) - jak to opravit?

[Michal Grézl]

2015-11-05 19:21 GMT+01:00 Marián Kyral :
> Ahoj,
> tak jsem teď vkládal rozcestníky z víkendu (přes web) a hned u toho prvního
> se mi povedlo zadat špatné ref a u dvou dalších špatné souřadnice (neměl
> jsem je v exifu).
>
> Tak jsem hledal jak to opravit. Našel jsem editor, ale tam žádné opravy
> nejdou. Navíc jsem zjistil, že se ani jedno ref. neuložilo :-(
> Jsou to rozcestníky 3459 až 3466.
>
> A u těch dvou fotek rozcestníků bez souřadnic jsem na té náhledové mapě
> dvakrát klikl na přibližné místo jejich umístění (mohlo by to jít ještě více
> přiblížit) - vyplnily se souřadnice. Bohužel jsem si je nezkontroloval a z
> editoru jsem zjistil, že se obě fotky nahrály se souřadnicemi někde v lese
> :-(
>
> Jsou to rozcestníky 3468 a 3469. Správné umístěné je
> http://www.openstreetmap.org/node/3814562080 a
> http://www.openstreetmap.org/node/2298307768
>
> Můžeš to prosím opravit, případně mi poradit jak na to? (Jestli to je vůbec
> možné). A je to chyba u mne, nebo na serveru? Používám Firefox 41.0.2 na
> Gentoo.

souradnice opraveny, zoom zvetsen na 18.
Posilani refu bylo blbe udelane, melo by to byt opravene

> A jak se vlastně to okno pro nahrávání na webu správně používá? Jak tam
> případně naklikám ty správné souřadnice? Nebo si je musím zjistit jinde?

Pokud ma fotka souradnice v exifu, necha se 0,0.
Nebo se zaskrtne zaskrtavatko exif, coz ovsem pouze zmeni souradnice
na 0,0 a zasedne je:).

> Ještě návrhy, co by tedy chtělo zlepšit:
>
> *) umožnit větší přiblížení náhledové mapy

done

> *) vylepšit to naklikávání souřadnic - ideálně s nějakou vizuální odezvou a
> možností daným bodem následně posouvat

Posouvani bodu by mohlo byt narocnejsi, uvidime.

> *) nějak lépe zviditelnit fakt, že bylo nahrávání dokončeno. Nevím jak to
> mají ostatní, ale po kliknutí na "nahrát soubor" se mi dole, těsně pod
> hranou toho dialogu, na chvíli objeví text o tom, že se nahrává a pak zmizí.
> Ale v dialogu samotném se nic nezmění. Takže se mi stalo, že jsem se
> pokoušel nahrát ten samý obrázek ještě jednou - to naštěstí nejde. Chtělo by
> to ten dialog trochu roztáhnout, aby se tam vešlo všechno (asi se to
> posunulo mimo po přidání políček pro ref) a po úspěšném nahrání rozcestníku
> by se tam mohla objevit nějaká zelená fajfka a zároveň by se ten dialog
> vyčistil (vyprázdnilo by se políčko s názvem souboru a ref) A kdyby se ta
> mapa zároveň posunula na souřadnice toho nově nahraného rozcestníku, to by
> bylo úplně boží ;-)

Vizualni kontrola uploadu ,resetovani, posunuti - neni problem.
Predelam ten dialog do jquery a pak bude mnohem jednodussi delat zmeny.

> Ale úplně nejlepší by bylo umožnit nahrát více fotek najednou. Nejprve si
> vyberu fotky, ty se nejprve nahrají na server na nějaké dočasné umístění, u
> každé se zobrazí poloha na mapě dle exifu, případně tam bude žádost o zadání
> souřadnic, pokud chybí exif. Zároveň budu mít možnost doplnit ref a změnit
> typ. A až bude všechno hotovo, kliknu na tlačítko uložit, které změny uloží
> do databáze. Pokud na uložit nekliknu, fotky se do databáze neuloží a po
> nějaké době se smažou.
>
> Takhle to třeba funguje na Flickr.com.

Je moznost domluvit se jednotlive na predani (upload, download)
baliku. Atomaticky to urcite delat nebudu, nemam zdroje k umozneni
nahravani gigovych fajlu.

> V podstatě by stačilo nahrát fotky a zobrazit je v tom editoru (až ho
> dopíšeš) :-D
>
> Jo a ještě, co takhle implementovat přihlašování pomocí
> http://wiki.openstreetmap.org/wiki/OAuth ?

Nejaka forma prihlasovani byt musi, to je jasne.

> Pomohl bych, bohužel já a javascript se nemáme rádi.
>
> uff,
> jsem se nějak rozepsal. Těm co dočetli až do konce gratuluji :-D
>
> Mapování a rozcestníků zvláště zdar.
> Marián
>

-- 
Michal Grézl
http://openstreetmap.cz

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

[Talk-us] Importing Buildings and Addresses for Austin, Texas

[Andy Wilson]

We would would like to import buildings and addresses for Austin, Texas and
surrounding areas. Our plan on the OSM wiki:
https://wiki.openstreetmap.org/wiki/Austin,_TX/Buildings_Import
Processed data files for import can be found here:
https://github.com/wilsaj/atx-buildings/tree/with-import-data/osm

I should note that we had a bit of a false start on import the today. I
thought we were ok to begin the import, but we were asked to stop. This is
my fault; I misunderstood the import review process. We are now paused and
awaiting feedback and approval from this list before continuing.

If you could find time to look things over, we would really appreciate it.

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

[OSM-ja] Help with translating diary posts

[Arun Ganesh]

こんにちは
Some big news, as part of the Japan highway realignment, we just finished
Tokyo and now the Nagoya project is available:
http://tasks.teachosm.org/project/104

Also for those following the OSM dairies, there are a couple of Japan
related posts which would be great to have translated for the benefit of
the Japanese readers:

   - https://www.openstreetmap.org/user/pratikyadav/diary/36280
   - https://www.openstreetmap.org/user/PlaneMad/diary/36262

If there is someone experienced with English > Japanese translation, do get
in touch. It would be great to collaborate on content that can help build
more interest in OSM in Japan and grow the community.

PS: Google translate is horrible goo.gl/hLJuvN :)

-- 
Arun Ganesh
(planemad) 

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

Re: [Talk-it] 7 novembre, Mapping Party a Piazzola sul Brenta (PD)

[Paolo Monegato]

Nel caso qualcuno si chiedesse com'è andata...

Ci siamo ritrovati più o meno all'orario previsto (10:30). Per chi si 
conosceva già è stato facile ritrovarsi, per gli altri direi che la 
pettorina gialla di OSM che aveva addosso Volker è stata di grande aiuto.
Prima di cominciare ci siamo organizzati dividendoci zone e mansioni. 
Eravamo in 7 mappatori (più uno in erba, il figlioletto del mapper 
autoctono), 4 con precedenti esperienze in altri mapping, altri 3 al 
primo mapping e con diversa esperienza per quanto riguarda i contributi 
su OSM. Dunque all'inizio è stato necessario anche fare una breve 
spiegazione sui metodi che avevamo a disposizione per mappare.
2 si sono dedicati a Mapillary [1], 2 con Vespucci si sono dedicati ai 
civici, mentre gli altri 3 sono andati di Field Papers (uno, che aveva 
dei FP con uno zoom maggiore, s'è dedicato alla toponomastica; gli altri 
2 al resto).


Dopo aver mappato un bel po' ci siamo ritrovati tra le 13 e le 13:30 e 
siamo andati a mangiare. Tra una portata ed una chiacchierata [2] 
abbiamo fatto le 15:30/16... Era dunque già arrivata l'ora di salutarci 
e non c'è stato il tempo di mappare un altro po' (magari facendo provare 
a chi aveva mappato con Vespucci i FP, e viceversa).


Per evitare conflitti di edizioni i dati verranno inseriti pian piano 
(prima i civici, poi il resto). Al momento so che la parte mapillary è 
già stata caricata, mentre per OSM qualche dato è già stato inserito, ma 
siamo appena all'inizio.
Come nostra consuetudine all'interno del commento del changeset c'è un 
esplicito riferimento al Mapping, dunque chi vuole tenere d'occhio la 
situazione può farlo molto comodamente.



Chiudo invitando tutti ad organizzare dei bei mapping. Perché è il modo 
migliore per venire a contatto con certi strumenti utili per mappare 
(dai Field Papers ad editor tipo Vespucci). Perché si incontra sempre 
gente interessante (tra l'altro spesso si scopre di avere conoscenze 
comuni). E perché è l'unico modo per fare comunità.


ciao
Paolo M

[1] a proposito, chi volesse usare le foto per ricavarci qualcosa da 
mappare è benvenuto. Le foto sono già online.
[2] tra le altre cose son venute fuori alcune cosucce interessanti: 
dall'opportunità di far qualcosa con anche l'amministrazione locale (che 
pare sia sensibile); alla necessità, per i poco avvezzi alla sintassi 
wikipediana, di avere VisualEditor anche sul wiki di OSM...


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

[Talk-es] Puntos kilométricos

[Juanma M. R.]

Hola,

Estoy intentando extraer los PKs de OSM pero me salen pocos (<300). No sé
si los estoy buscando mal o realmente es que no están en OSM. Estoy tirando
de una BDD de Nominatim con el tag "highway=milestone" pero no saco más.

Si quiero extraer los pks de OSM ¿cómo debo hacerlo? ¿Debo buscar por algún
tag más? Es que también he visto que este tag no está aprobado aunque esta
extendido su uso.

Un saludo,
Juan Manuel Moreno Rivera. 
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] [OSMOSE] purge d'ingération des adresses de Montpellier

[Jérôme Seigneuret]

Je reviens sur la purge de données

Les propositions d'intégrations (en tous cas pour les données adresses de
Montpellier) ne sont pas retirées même si les adresses existent déjà dans
OSM
exemple : 553 Rue Valéry Larbaud, Montpellier

Adresse intégrée en 2013 et c'est pareil pour beaucoup d'autres. Nominatim
les trouve très bien. La plus part des adresses traitées n'ont pas le nom
de rue intégré dans le nœud portant l'adresse mais la relation est faite
via AssociatedStreet

http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.634557=3.883908=Mapnik=T==1%2C2%2C3==

Et-il possible de forcer la suppression via Nominatim et non un "corrigé" à
la main pour tous les points existant.

Merci,
Jérôme


Le 6 novembre 2015 17:02, Christian Quest  a écrit
:

> Le retour à la normale de cadastre.openstreetmap.fr ne devrait plus
> tarder...
>
>
> On 06/11/2015 10:59, Vincent de Château-Thierry wrote:
> > Bonjour,
> >
> >> De: "Nicolas Moyroud" 
> >>
> >> De même pour cadastre.openstreetmap.fr.
> >> C'est bien dommage ces outils hors service ont tendance à réfréner
> >> quelque peu mes pulsions de contribution ;-)
> > Le problème sur cadastre.openstreetmap.fr est pris en charge mais pas
> encore résolu. Comme indiqué ici :
> > https://github.com/osm-fr/bano/issues/104 on espère une issue rapide.
> >
> > vincent
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Philippe Verdy]

La syntaxe avec C11 est-elle bien supportée et compatible avec l'ISO ou un
format RFC connu pour les dates? En tout cas celle avec tilde ou avec un
mot clé supplémentaire comme "mid" n'est documentée nulle part. Pour
l'instant start_daye n'est documentée qu'avec une date précise jusqu'à la
seconde,  mais au minimum avec l'année complète et rien pour les autres
intervalles d'incertitude.
Le 9 nov. 2015 13:50, "dHuy Pierre"  a écrit :

> Il y aussi start_date=C11 ou ~C11 ou même mid C11 pour le milieu du siècle
> qui correspond très bien plutôt que d'inventer un nouveau tag.
>
>
>
> Le Lundi 9 novembre 2015 11h21, Philippe Verdy  a
> écrit :
>
>
> tu peux proposer "historic:century=11" si la classification par époque ou
> civilisation est difficile (d'ailleurs elle varie selon les pays ou
> cultures, ce qui est documenté est difficile à standardiser et faire
> accepter partout).
> le "start_date=*" est plutôt réservé à noter des dates précises (avec un
> format compatible ISO 8601 contenant au minimum une année complète), mais
> le XIe siècle n'est pas assez précis on ne peut pas non plus mettre
> "start_date=1001-1100" (format incompatible posant problème),
> start_date=1001 (oui, le XIe siècle commence l'année suivant l'an mil) ou
> start_date=1050 (milieu du siècle) serait au contraire trop précis (rien
> n'indique que c'est en fait une estimation à plus ou mois 50 ans près).
>
> Le 9 novembre 2015 11:07, Jérôme Seigneuret  a
> écrit :
>
> Bonjour, en faisant un fix sur le nom d'une église je me retrouve à avoir:
> Église ST Barthélémy XIième siècle que je corrige en Église
> Saint-Barthélémy-de-Baillarguet
>
> Mon problème est d'ajouter l'information lié au XI ème siècle
> > période du moyen age central + précision sur le siècle
>
> Ducoup je regarde du coté des tags
> http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilization
> historic:period =
> start_date =
>
> Je me rend compte que rien n'est précisé sur les siècles tel que l'on a
> l'habitude de l'utilisé d'une part et que les grandes périodes de notre
> civilisation ne sont pas détaillé:
> préhistoire et protohistoire c'est OK
>
>- *historic:civilization*=prehistoric
>- *historic:civilization*=protohistoric
>
>
> Reste les périodes après JC et les périodes spécifique à des régions
>
> moyen-age :vie ‑xve
>
> haut Moyen Âge = : vie ‑ xe siècle
> Moyen Âge central : xie ‑ xiiie siècle
> Moyen Âge tardif  :
> xive ‑ xve siècle
>
>
> époque moderne :
>
> Époque moderne antérieure :1492 – 1792
>
> époque contemporaine :
>
> Époque moderne I : 1792 – 1920
> Époque moderne II : 1920 à nos jours
>
>
> Bonne journée
> Jérôme
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Proposal: Sunset ref=* on ways in, favor of relations

[Kevin Kenny]

On 11/08/2015 09:04 PM, Paul Norman wrote:
Phil's demo was an excellent proof of concept of pictorial shields 
from route relations, but isn't something that can be reasonably 
incorporated into a stylesheet as-is. 
https://github.com/gravitystorm/openstreetmap-carto/issues/596 is the 
OpenStreetMap Carto issue for shields from relations, 
https://github.com/gravitystorm/openstreetmap-carto/issues/508 is the 
one for pictorial shields.


Forgive my ignorance. I'm coming in as a consumer of the data and as a 
fairly inexperienced mapper. My biggest field mapping project so far has 
been http://www.openstreetmap.org/relation/4286650 - which pales to 
insignificance compared with the whole cities that some of you take on.


Nevertheless, I found that project interestingly related to the current 
discussion, because the trail in question is concurrent with named roads 
on portions of its route, and there are therefore ways that are 
intentionally not tagged with its name, lest, for instance, a highway 
router become confused. Having the relation available was the only ready 
way that I had to extract a single center line from the OSM data, which 
was then used to produce http://www.nptrail.org/?page_id=59 . It would 
have been challenging to assemble the ways into something coherent for 
measuring the distances without having the route relation.


In the issue on Github, you remark:
"I'm contemplating closing this. As above, there are currently serious 
data issues in the US that prevent route relations from being used for 
rendering shields. If someone wants to take up the data quality issue, I 
could leave it open or re-open in the future, but unless it changes, I 
just can't see any way to make use of the route relations."


That gives a horribly bleak outlook. I'm sure I'm misunderstanding what 
you say there, but it comes across as saying that the problem is forever 
unfixable, and that the hard work people have put in so far into 
generating route relations is all for naught, either because it remains 
incomplete or because the data model of route relations is fundamentally 
incompatible with shield rendering.


I do tend to think that, in the long run, deriving the shield from both 
the tagging on the way and on the relation is going to be problematic, 
simply because data maintained in two places are always going to be 
inconsistent. Maintaining the data exclusively on the way is going to be 
brittle, because of the issues of concurrent routes. Maintaining the 
data exclusively on the relation is going perhaps to be too difficult 
for novice mappers.


The result is that the data quality issues of which you speak will be 
always with us.


Is this an accurate summary of your position?

If so, I'd like to explore what has to change to break the log jam. My 
OSM experience has been limited to putting data in and taking data out, 
but I'm a pretty fair hand at SQL and GIS processing - your long query 
doesn't scare me, if the issue is programming. If the issue is that data 
are entered inconsistently, Maproulette has often been successful in the 
past at getting the data cleaned up. If the issue is fundamentally 
political, well, I'm probably not the man for that one. In John Adams's 
words, I'm "obnoxious and disliked."


--
73 de ke9tv/2, Kevin

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

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[dHuy Pierre]

Je ne pense pas que ça soit ISO effectivement mais largement utilisé et 
documenté sur le Wiki, sur le lien fourni plus haut d'ailleurs. Les logiciels 
comme josm renvoie d'ailleurs à cette page pour ce type de clef donc c'est 
plutôt largement utilisé. Et puis c'est toujours mieux que d'ajouter un tag qui 
ne sera utilisé que par peu de personnes. 


 Le Lundi 9 novembre 2015 15h31, Philippe Verdy  a 
écrit :
   

 La syntaxe avec C11 est-elle bien supportée et compatible avec l'ISO ou un 
format RFC connu pour les dates? En tout cas celle avec tilde ou avec un mot 
clé supplémentaire comme "mid" n'est documentée nulle part. Pour l'instant 
start_daye n'est documentée qu'avec une date précise jusqu'à la seconde,  mais 
au minimum avec l'année complète et rien pour les autres intervalles 
d'incertitude. Le 9 nov. 2015 13:50, "dHuy Pierre"  a écrit :

Il y aussi start_date=C11 ou ~C11 ou même mid C11 pour le milieu du siècle qui 
correspond très bien plutôt que d'inventer un nouveau tag. 


 Le Lundi 9 novembre 2015 11h21, Philippe Verdy  a 
écrit :
   

 tu peux proposer "historic:century=11" si la classification par époque ou 
civilisation est difficile (d'ailleurs elle varie selon les pays ou cultures, 
ce qui est documenté est difficile à standardiser et faire accepter partout).le 
"start_date=*" est plutôt réservé à noter des dates précises (avec un format 
compatible ISO 8601 contenant au minimum une année complète), mais le XIe 
siècle n'est pas assez précis on ne peut pas non plus mettre 
"start_date=1001-1100" (format incompatible posant problème), start_date=1001 
(oui, le XIe siècle commence l'année suivant l'an mil) ou start_date=1050 
(milieu du siècle) serait au contraire trop précis (rien n'indique que c'est en 
fait une estimation à plus ou mois 50 ans près).
Le 9 novembre 2015 11:07, Jérôme Seigneuret  a écrit :

Bonjour, en faisant un fix sur le nom d'une église je me retrouve à 
avoir:Église ST Barthélémy XIième siècle que je corrige en Église 
Saint-Barthélémy-de-Baillarguet
Mon problème est d'ajouter l'information lié au XI ème siècle> période du moyen 
age central + précision sur le siècle
Ducoup je regarde du coté des tags 
http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilizationhistoric:period=
start_date=

Je me rend compte que rien n'est précisé sur les siècles tel que l'on a 
l'habitude de l'utilisé d'une part et que les grandes périodes de notre 
civilisation ne sont pas détaillé:
préhistoire et protohistoire c'est OK   
   - historic:civilization=prehistoric 
   - historic:civilization=protohistoric 

Reste les périodes après JC et les périodes spécifique à des régions
moyen-age :vie ‑xve
haut Moyen Âge = : vie ‑ xe siècleMoyen Âge central : xie ‑ xiiie siècleMoyen 
Âge tardif : xive ‑ xve siècle

époque moderne :
Époque moderne antérieure :1492 – 1792
époque contemporaine :

Époque moderne I : 1792 – 1920Époque moderne II : 1920 à nos jours


Bonne journéeJérôme

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




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


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




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

Re: [OSM-talk-fr] OpenSolarMap...

[Florian LAINEZ]

   - Dans le cas de toits à 4 pans, je mets en général "?", est-ce le cas
   de tout le monde ?

oui, et cela m'arrive très souvent.

Le 9 novembre 2015 11:37, Philippe Verdy  a écrit :

>
>
> Le 9 novembre 2015 11:08, Pierre GRANJON  a écrit :
>
>> Bonjour à tous,
>> Très bonne idée ce projet, et l'outil de crowdsourcing donne envie de
>> participer !
>> J'ai fait 200 ajouts, ça marche très bien mais j'ai quelques commentaires
>> :
>>
>>- Dans le cas de toits à 4 pans, je mets en général "?", est-ce le
>>cas de tout le monde ?
>>
>> Si les deux autres pans sont seulemnt sur les pignons  et que la plus
> grande partie du toit est à double pente, il men semble qu'on peut ignorer
> ces pignons.
>
> D'ailleurs la classification demandée se contente juste de chercher deux
> orientations possibles pour les double pentes, ou le toit plat (difficile
> malgré tout de voir sur une photo aérienne si le toit est réellement plat
> ou en pente, et encore plus de voir son orientation réelle qui peut très
> bien être vers l'est ou le nord et pas favorable aux panneaux solaires: cas
> assez fréquents pour les toits métailliques de batiments commerciaux,
> industriels ou agricoles, sachant que bon nombre de batiments d'élevage
> sont faits avec des orientations favorables destinées à optimiser les couts
> de chauffage/climatisation et augmenter le rendement énergétique global,
> même sans aucun panneau solaire: cette étude thermique des batiments
> agricoles se fait depuis de nombreuses décennies: voir avec le CEMAGREF qui
> a fait des études avec les chambres d'agricultures et syndicats ou
> coopératives agricoles et même développé des logiciels pour ça, incluant
> aussi l'études des matériaux, des données météo moyennes, et les
> équipements de ventilisation ou récupérateurs de chaleur).
>
>>
>>- Enfin, j'ai repéré quelques panneaux solaires déjà existants, pour
>>lesquels j'ai tout  de même renseigné l'orientation. Ca pourrait être
>>l'occasion de recenser l'existant en panneaux solaires ?
>>
>> S'il y a des panneaux solaires visibles, l'emplacement est à priori
> favorable pour ça et ce serait utile de pouvoir cliquer sur une icone pour
> les toits déjà équipés, sans même avoir à saisir l'orientatation réelle qui
> aura peu d'intérêt pour cette application.
>
> De plus dans de nombreuses zones urbaines, les toits de batiments mitoyens
> d'une même rue adoptent une orientation commune (en cas d'ambiguité sur un
> ds batiments les batiments voisins mieux visibles peuvent donner une
> indication du potentiel sur toute une rue, notamment s'il y a déjà des
> batiments équipés).
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

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

Re: [Talk-it] La mappa di OSM ha un nuovo schema colori

[Martin Koppenhoefer]

2015-11-09 13:34 GMT+01:00 Paolo Monegato :

> ps: ovviamente conosco già F4 ;-)
>


si, ma il London Eye è pessimo ;-)

qui di meno, ma è cmq evidente che qualcosa non va:
http://demo.f4map.com/#lat=51.5003407=-0.1268152=17=68.254=125.191
una foto dalla stessa posizione:
http://anglotopia.wpengine.netdna-cdn.com/wp-content/uploads/2012/11/JasonHawkes-0978.jpg


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

[Talk-dk] Den gamle avlsgård

[Niels Elgaard Larsen]

Hvordan ville i tagge Den Gamle Avlsgård?
http://www.dengamleavlsgaard.dk/

Jeg har lidt svært ved at placere den i OSM hierarkierne.

-- 
Niels Elgaard Larsen



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

Re: [OSM-talk-fr] [OSMOSE] purge d'ingération des adresses de Montpellier

[Frédéric Rodrigo]

La distance de rapprochement est de 15m, ça ne semple pas suffisant pour 
Montpellier compte tenu que l'OpenData à l'air d'être à l'entré de la 
propriété et que les données OSM dans ce coin sont sur l'entré du bâtiment.


L'analyse Osmose ne tient pas compte de la rue, juste le numéro.


Le 09/11/2015 15:15, Jérôme Seigneuret a écrit :

Je reviens sur la purge de données

Les propositions d'intégrations (en tous cas pour les données adresses 
de Montpellier) ne sont pas retirées même si les adresses existent 
déjà dans OSM

exemple : 553 Rue Valéry Larbaud, Montpellier

Adresse intégrée en 2013 et c'est pareil pour beaucoup d'autres. 
Nominatim les trouve très bien. La plus part des adresses traitées 
n'ont pas le nom de rue intégré dans le nœud portant l'adresse mais la 
relation est faite via AssociatedStreet


http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.634557=3.883908=Mapnik=T==1%2C2%2C3==

Et-il possible de forcer la suppression via Nominatim et non un 
"corrigé" à la main pour tous les points existant.


Merci,
Jérôme


Le 6 novembre 2015 17:02, Christian Quest > a écrit :


Le retour à la normale de cadastre.openstreetmap.fr
 ne devrait plus
tarder...


On 06/11/2015 10:59, Vincent de Château-Thierry wrote:
> Bonjour,
>
>> De: "Nicolas Moyroud" >
>>
>> De même pour cadastre.openstreetmap.fr
.
>> C'est bien dommage ces outils hors service ont tendance à réfréner
>> quelque peu mes pulsions de contribution ;-)
> Le problème sur cadastre.openstreetmap.fr
 est pris en charge mais pas
encore résolu. Comme indiqué ici :
> https://github.com/osm-fr/bano/issues/104 on espère une issue
rapide.
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr

--
Christian Quest - OpenStreetMap France


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




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



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

Re: [OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[Philippe Verdy]

Regarde dans tes spams,  je l'ai déjà signalé en privé à Bernard,  ses
mails sont envoyés par un serveur SMTP non authentifié par son fournisseur
de messagerie la poste.net... Sa signature DKIM est invalide... Gmail par
exemple classe ses messages en spam
Le 9 nov. 2015 21:08, "Jérôme Seigneuret"  a
écrit :

> Normal que l'on ne voit pas le message initial de Bernard dans la liste?
>
> Le 9 novembre 2015 20:59, David Crochet  a écrit :
>
>> Bonjour
>>
>> Le 09/11/2015 19:39, bernard a écrit :
>>
>>> Bonjour,
>>> Je viens de remarquer que les couleurs de la page de téléchargement de
>>> JOSM ont changé.
>>> Les Primary prennent la couleur des secondary
>>> Les Secondary celles des Tertiary
>>> Les Tertiary n'en a plus.
>>> Je n'ai touché à aucun réglage
>>>
>>
>> Normal
>>
>>
>>> Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
>>> dialogue qui nécessite un clic ... inutile.
>>> Pour quelle raison cette modification?
>>>
>>
>> JOSM est un logiciel en constante évolution. S'il y a évolution, c'est
>> qu'il y a demande d'évolution.
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[Philippe Verdy]

Même diagnostic pour toi Vincent,  puisque tu es à la poste..  Toi aussi
t'es messages vont automatiquement dans la boîte spam. Le problème est donc
à la poste sur leurs serveurs SMTP sortants mal configurés...
Le 9 nov. 2015 21:38, "Vincent de Château-Thierry"  a
écrit :

> Bonsoir,
>
> Le 09/11/2015 21:07, Jérôme Seigneuret a écrit :
>
>> Normal que l'on ne voit pas le message initial de Bernard dans la liste?
>>
>
> Il est bien là :
> https://lists.openstreetmap.org/pipermail/talk-fr/2015-November/078585.html
>
> Le 9 novembre 2015 20:59, David Crochet > > a écrit :
>>
>> Bonjour
>>
>> Le 09/11/2015 19:39, bernard a écrit :
>>
>> Bonjour,
>> Je viens de remarquer que les couleurs de la page de
>> téléchargement de
>> JOSM ont changé.
>> Les Primary prennent la couleur des secondary
>> Les Secondary celles des Tertiary
>> Les Tertiary n'en a plus.
>> Je n'ai touché à aucun réglage
>>
>> Normal
>>
>
> La charte par défaut d'osm.org a changé il y a une semaine :
> https://blog.openstreetmap.org/2015/10/30/openstreetmap-org-map-changing/
> C'est celle qui s'affiche aussi dans JOSM par défaut. On l'a évoqué ici :
> https://lists.openstreetmap.org/pipermail/talk-fr/2015-October/078440.html
>
>
> Par ailleurs, lors de la coupure d'un way, il s'affiche une boite
>> de
>> dialogue qui nécessite un clic ... inutile.
>> Pour quelle raison cette modification?
>>
>>
>> JOSM est un logiciel en constante évolution. S'il y a évolution,
>> c'est qu'il y a demande d'évolution.
>>
>
> Cette évolution fait la "une" des changements de la dernière version
> stable : https://josm.openstreetmap.de/wiki/Fr%3AStartupPage
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-us] San Diego Address Import Update

[Hans De Kryger]

Late last year September 2014 i sent an email about a 2009 San Diego
address import that needed it's street names expanded by a bot. It was
imported before the community had an acceptance of expanding street names.
Any chance some one can run a bot to expand them. I have no experience on
that. Not home right now, but you search anywhere near San Diego and check
an address and you'll see what I'm talking about.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] OpenSolarMap...

[osm . sanspourriel]

Oui, effectivement on en rencontre beaucoup.
La règle est simple, comme dit par Christian, tout ce qui n'est pas N/S, 
E/O ou plat est ?.
? étant donc autre et non une question (l'iconographie est ici peu 
explicite, et quand je ne sais pas plutôt que de répondre, je rafraichis 
la page plutôt que de répondre "autre".
Comme pour les sondages, NSP (Ne Se Prononce Pas) est une réponse 
différente de "autre".
"autre" c'est toit de travers par rapport aux points cardinaux, et qui 
n'est pas plat.

"NSP" c'est un toit mal identifiable.

Je comprends le soucis de simplification, mais là on risque de perdre en 
qualité.
Arrêter de demander pour un toit à peu près plat dont la vue aérienne 
est insuffisante aboutira à une classification en ? c'est à dire mauvais 
alors que la "bonne" réponse est qu'il faut regarder de plus près.


Sinon pouvoir étendre la sélection aux bâtiments de la rue s'ils ont 
même orientation permettrait de gagner du temps.


J'allais oublier, une requête overpass sur les highway sans 
landuse=forest ou forte densité urbaine à côté va pouvoir suffire :

http://www.parismatch.com/Actu/Environnement/Les-routes-solaires-l-energie-de-demain-Revetement-photovoltaique-861963
;-)

N'oublions pas que les talus nord des autoroutes est-ouest (murs 
antibruits par exemple) sont aussi de bon emplacements.


Jean-Yvon

Le 09/11/2015 15:53, Florian LAINEZ - winner...@free.fr a écrit :


  * Dans le cas de toits à 4 pans, je mets en général "?", est-ce le
cas de tout le monde ?

oui, et cela m'arrive très souvent.


Le 9 novembre 2015 11:37, Philippe Verdy > a écrit :




Le 9 novembre 2015 11:08, Pierre GRANJON > a écrit :

Bonjour à tous,
Très bonne idée ce projet, et l'outil de crowdsourcing donne
envie de participer !
J'ai fait 200 ajouts, ça marche très bien mais j'ai quelques
commentaires :

  * Dans le cas de toits à 4 pans, je mets en général "?",
est-ce le cas de tout le monde ?

Si les deux autres pans sont seulemnt sur les pignons  et que la
plus grande partie du toit est à double pente, il men semble qu'on
peut ignorer ces pignons.

D'ailleurs la classification demandée se contente juste de
chercher deux orientations possibles pour les double pentes, ou le
toit plat (difficile malgré tout de voir sur une photo aérienne si
le toit est réellement plat ou en pente, et encore plus de voir
son orientation réelle qui peut très bien être vers l'est ou le
nord et pas favorable aux panneaux solaires: cas assez fréquents
pour les toits métailliques de batiments commerciaux, industriels
ou agricoles, sachant que bon nombre de batiments d'élevage sont
faits avec des orientations favorables destinées à optimiser les
couts de chauffage/climatisation et augmenter le rendement
énergétique global, même sans aucun panneau solaire: cette étude
thermique des batiments agricoles se fait depuis de nombreuses
décennies: voir avec le CEMAGREF qui a fait des études avec les
chambres d'agricultures et syndicats ou coopératives agricoles et
même développé des logiciels pour ça, incluant aussi l'études des
matériaux, des données météo moyennes, et les équipements de
ventilisation ou récupérateurs de chaleur).




--

*Florian Lainez*

@overflorian 


___
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-us] San Diego Address Import Update

[Tod Fitch]

I think you are referring to this change set: 
https://www.openstreetmap.org/changeset/3411425

I noticed errors in it the other week when adding a restaurant in Pine Valley 
and noted on the mail list: 
https://lists.openstreetmap.org/pipermail/talk-us/2015-November/015634.html

It appears to me that there are more things wrong than just the street name 
expansion, for instance all the addresses in Pine Valley claim to be in the 
city of San Diego (the boundary for which is quite some distance away).

That import needs to be cleaned up but I hope some local mapper(s) can take the 
lead. I don’t live in the area but will be driving through there from time to 
time in the next couple of months and will fix the very limited areas I can 
personally survey.

-Tod

> On Nov 9, 2015, at 2:34 PM, Hans De Kryger  wrote:
> 
> Late last year September 2014 i sent an email about a 2009 San Diego address 
> import that needed it's street names expanded by a bot. It was imported 
> before the community had an acceptance of expanding street names. Any chance 
> some one can run a bot to expand them. I have no experience on that. Not home 
> right now, but you search anywhere near San Diego and check an address and 
> you'll see what I'm talking about.
> 

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

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[osm . sanspourriel]

Moi aussi ça me va.

Pour plus de clarté je suis pour l'utilisation des tirets dans l'ISO 
8601 pour désigner des dates.

Soit :
1001..1099 - 1492-02-12..1492-02-13
C'est moins cabalistique.

Pour la fameuse année zéro, comme vous de savez pas à 4 ans près (ou 
plus) quand le Jésus Christ a poussé son premier Christ, heu cri, donner 
des dates antérieures à une précision de +/- 1 an, on s'en fiche (pour 
les données qui nous concernent).


Jean-Yvon

Le 09/11/2015 17:10, Jérôme Seigneuret - jseigneuret-...@yahoo.fr a écrit :


Si on voulait préciser une construction s'étalant du 11e siècle au
15e, cela donnerait "1001..1099 - 1401..1499". Si on peut dater
plus précisément une date, par exemple février 1492 pour la
seconde borne au lieu du simple 15e siècle, cela donnerait
"1001..1099 - 1492-02"

Je trouve ça plutôt intéressant

Mais si la construction s'est achevée encore plus précisément le
12 ou le 13 février, cela donnerait "1001..1099 -
1492-02-12..1492-02-13" (les 4 dates mentionnée sont toutes en
format compatible ISO 8601 (lequel format n'inclut aucune espace
ni aucun point... mais admet qu'on puisse supprimer les
séparateurs "-" entre les composants année-mois-jour à condition
de mettre les années sur 4 chiffres minimum, donc autoriserait
aussi qu'on utilise pour nos intervalles: ""1001..1099 -
14920212..14920213").

Moi ça me va




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

Re: [Talk-pe] INVITACIÓN A COMUNIDAD OSM PERÚ AL EVENTO GEOMÁTICA LIBRE (CHICLAYO)

[Omar Vega Ramos]

Hola Juan

Como activista del software libre formo parte del equipo de hackers de
Parabola GNU/Linux-libre [0] [1], que es una de las distribuciones
avaladas por la Free Software Foundation [2] .

Para contribuir en OpenStreetMap existen varios editores [3], muchos de
estos son Software Libre. Entre los editores mas conocidos están iD [4],
Potlach 2 [5] y JOSM [6], todos estos son Software Libre.

[0] https://www.parabola.nu/
[1] https://es.wikipedia.org/wiki/Parabola_GNU/Linux-libre
[2] https://fsf.org/
[3] https://wiki.openstreetmap.org/wiki/Editors
[4] https://wiki.openstreetmap.org/wiki/ID
[5] https://wiki.openstreetmap.org/wiki/Potlatch_2
[6] https://wiki.openstreetmap.org/wiki/JOSM

Saludos

-- 
Omar Vega

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

[OSM-talk] highway=residential_link

[Andrew Guertin]

A question recently came up as to whether highway=residential_link is a 
meaningful tag or whether uses of it should be changed to some other 
value (like highway=residential or highway=service).


This tag has no description in the wiki, though it is analogous to the 
other highway=*_link types described on 
https://wiki.openstreetmap.org/wiki/Highway_link .


There are only 23 current uses of the tag, but many others were recently 
removed. By going through (by hand) the recent edits of an editor who 
removed them, I've come up with a list of 58 more objects that used it 
[1]. If anyone knows of a programmatic way of finding objects that 
previously used a tag, I'd be interested to know it.


Of those 81 current and recent uses that I worked with,
* They occurred in North America (36), South America (30), Europe (11), 
and Australia (4)
* 35 were added in 2015, 38 were added in 2014, and the remaining 8 were 
added in 2010-2013

* I count 33 unique users that added the tag
* 19 of the uses had a value for name="*", 62 did not have a name

* Of the 36 North American uses, I personally think 
highway=residential_link makes sense on 16 of them, while 12 should be a 
higher highway=*_link and 8 should not be a _link at all.



highway=residential_link is not currently rendered in 
openstreetmap-carto, and a request for adding it in February 2015 was 
declined 
(https://github.com/gravitystorm/openstreetmap-carto/issues/1280), due 
to low usage and being undocumented. That bug mentions that it is 
supported in various routing apps, and it WAS supported in the HOT map 
style until that support was removed recently.



So the question is, should uses of highway=residential_link be edited 
away, should they be left as-is (unless a different highway type is 
clearly better), or should the tag be approved and documented?



--Andrew





[1] Objects that previously used highway=residential_link. This list was 
generated by hand, and might have some mistakes. Also, not all of these 
necessarily should have used the tag.


275610032, 275610033, 275610026, 275610025, 275355353, 269193467, 
268796394, 262798921, 262715792, 262287021, 259433293, 259433291, 
259136210, 256321591, 256321612, 256256231, 82529183, 256250694, 
256250692, 255858772, 255734560, 255734548, 255734547, 255734546, 
255285030, 255282915, 255282916, 242373220, 240563513, 238260570, 
237128774, 222995985, 318225690, 219160095, 200773019, 191613798, 
183497432, 174739362, 174739436, 173790274, 152304285, 95348547, 
87908508, 87908510, 87908507, 83285340, 54356292, 54356293, 45812108, 
45812107, 39722340, 35248433, 148015236, 35242001, 35121698, 35121488, 
18820600, 6086632, 6107802,




On 11/09/2015 01:39 AM, GerdP wrote:

I think this should really be discussed in the tagging list.
I only know a discussion in Germany which came to the
conclusion that tags like unclassified_link, residential_link and
service_link make not much sense:
http://forum.openstreetmap.org/viewtopic.php?id=26083
The wiki doesn't mention those _link types as well, and my
understanding is that only major roads have a link (if link
in english means what we call "Abfahrt/ Auffahrt" in Germany,
I would describe it as a lane that allows to decrease/increase
speed.




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

Re: [Talk-us] [Imports] Importing Buildings and Addresses for Austin, Texas

[Clifford Snow]

On Mon, Nov 9, 2015 at 6:40 PM, Andy Wilson 
wrote:

> 3. Efficiency. There are enough buildings in OSM already and as Martin
> pointed out, comparing them individually and properly merging tags, etc
> would be time consuming.


JOSM has a "Replace Geometry" tool found in the Util2 plugin that makes it
easy to merge old and new. Each building will have to be reviewed
individually. In some cases, the building in OSM might be newer but lacking
address information. In that case the address information will need to be
copies from the import to the existing building. It's harder, but with 3
year old data it is likely to occur.

Clifford


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

Re: [OSM-talk] highway=residential_link

[Andrew Guertin]

Oops, this was supposed to go to tagging...

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

Re: [Talk-us] San Diego Address Import Update

[Tod Fitch]

> On Nov 9, 2015, at 8:42 PM, Richard Welty  wrote:
> 
> maybe but i would do some more research before making an assumption.
> i'm aware of many postal city addresses that are in different counties
> than the
> "real" cities and i believe there are at least 4 cases where postal delivery
> crosses state lines.
> 

What is a “city” in US specific OSM terms?

I prefer a postal city definition as that is the most useful for routing 
purposes which I feel is the primary use of address data in OSM. Or are we 
dealing with some other concept of addr:city?

Using Pine Valley, California, as have been my examples for other posts in this 
thread, I see the administrative boundary for the city San Diego is probably 30 
miles away: The locations are neither within the boundary nor in the postal 
delivery area for the city of San Diego. To me that clearly indicates the 
addr:city=“San Diego" tags is wrong.

So what value to use for the addr:city tag values? There is an administrative 
boundary around the area that looks like it is from the original Tiger import 
with the name of “Pine Valley” as a “locality”. There is a post office there 
with a “Pine Valley” sign on the building. The ZIP codes that were imported on 
the change set for this area all are set to 91962. When I look up 91962 on the 
USPS official web site it returns “Pine Valley, CA” and only “Pine Valley, CA”. 
The USPS result page also says "Please use the default city whenever possible” 
which indicates they think everyone should use “Pine Valley”. There is no 
county, state or national border near by to confuse the issue.

Looking at adjacent “towns” (may only be census designated areas) I see the 
same thing. Just look at Guatay, CA a little west on the old main highway and 
you will see the same thing.

So what “more research before making an assumption” should be done in this 
area? I suspect a theoretical problem with a hypothetical general case is be 
being brought up when what I see in the data is a pretty straight forward issue 
of bad data that can be corrected.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Importing Buildings and Addresses for Austin, Texas

[Andy Wilson]

On Mon, Nov 9, 2015 at 12:59 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > Am 09.11.2015 um 18:07 schrieb Eric Ladner :
> >
> > Replacing existing hand drawn buildings with imports from the city's GIS
> system would probably be preferable given the quality of the hand drawn
> buildings.  (compare the outline in [1] to satellite imagery).
>
>
> it might depend, unlike the city's data the things in osm may vary a lot
> in level of detail and quality. Also there could be other information
> attached to these buildings so they should be carefully reviewed before any
> deletions are executed.
>
>
> cheers
> Martin



Thanks for taking time to look things over. Adding to what Martin said,
some of our reasons:

1. From the belief that individual contributions are more valuable as a
whole than contributions from an automated import process. We are trying to
grow a local OSM community in Austin, and I feel that throwing away the
work of past contributors works against that.

2. The data we are importing was collected about 3 years ago at this point,
so OSM data will be more relevant and up to date in some cases.

3. Efficiency. There are enough buildings in OSM already and as Martin
pointed out, comparing them individually and properly merging tags, etc
would be time consuming.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Importing Buildings and Addresses for Austin, Texas

[Eric Ladner]

I'll second Paul's bit rot on unique ID's comments.   They're all well and
good until somebody upgrades their GIS system, then all those unique ID's
get flushed down the drain.  And actually doing a conflation with hundreds
of thousands of buildings which may or may not have the ID's preserved over
years of editing is a daunting task in itself.

Also, I wouldn't be so concerned of the existing buildings.  Of the 4000 or
so existing buildings I looked at in Austin (and a good percentage of those
were the accidental import ones that I couldn't filter out), 90% of them
are poorly drawn contain only "building=yes" on them.  Most are hand drawn,
not orthogonal and only vaguely representative of the buildings on the
ground.

With the exception of the university buildings, it would be worth the time
to import the whole data set from CoA and find the conflicts at import time
and replace the existing geometry with the GIS system data.  I conflated
hundreds of buildings in the New Orleans import manually.  Time consuming?
Yes.  Worth it?  Yes.  The address data and decent building footprints
alone are worth it.

My 0.02.

On Mon, Nov 9, 2015 at 8:40 PM Andy Wilson 
wrote:

> On Mon, Nov 9, 2015 at 12:59 PM Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>>
>> sent from a phone
>>
>> > Am 09.11.2015 um 18:07 schrieb Eric Ladner :
>> >
>> > Replacing existing hand drawn buildings with imports from the city's
>> GIS system would probably be preferable given the quality of the hand drawn
>> buildings.  (compare the outline in [1] to satellite imagery).
>>
>>
>> it might depend, unlike the city's data the things in osm may vary a lot
>> in level of detail and quality. Also there could be other information
>> attached to these buildings so they should be carefully reviewed before any
>> deletions are executed.
>>
>>
>> cheers
>> Martin
>
>
>
> Thanks for taking time to look things over. Adding to what Martin said,
> some of our reasons:
>
> 1. From the belief that individual contributions are more valuable as a
> whole than contributions from an automated import process. We are trying to
> grow a local OSM community in Austin, and I feel that throwing away the
> work of past contributors works against that.
>
> 2. The data we are importing was collected about 3 years ago at this
> point, so OSM data will be more relevant and up to date in some cases.
>
> 3. Efficiency. There are enough buildings in OSM already and as Martin
> pointed out, comparing them individually and properly merging tags, etc
> would be time consuming.
>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] San Diego Address Import Update

[Richard Welty]

On 11/9/15 8:23 PM, Tod Fitch wrote:
> Perhaps true in general, but in this specific case the administrative 
> boundary for San Diego (1) is quite a long way from the post office in Pine 
> Valley (2)(3) and the Pine Valley post office is most likely to have a postal 
> name of “Pine Valley” as displayed on the front of the building (right next 
> to the restaurant I ate in last week and I saw it). And the post office is in 
> the administrative boundary for Pine Valley (4). (I was wrong earlier in 
> assuming that there was no administrative boundary for Pine Valley.)
>
maybe but i would do some more research before making an assumption.
i'm aware of many postal city addresses that are in different counties
than the
"real" cities and i believe there are at least 4 cases where postal delivery
crosses state lines.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




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

Re: [Talk-us] San Diego Address Import Update

[Hans De Kryger]

Thanks tod i really appreciate your help.
On Nov 9, 2015 8:43 PM, "Richard Welty"  wrote:

> On 11/9/15 8:23 PM, Tod Fitch wrote:
> > Perhaps true in general, but in this specific case the administrative
> boundary for San Diego (1) is quite a long way from the post office in Pine
> Valley (2)(3) and the Pine Valley post office is most likely to have a
> postal name of “Pine Valley” as displayed on the front of the building
> (right next to the restaurant I ate in last week and I saw it). And the
> post office is in the administrative boundary for Pine Valley (4). (I was
> wrong earlier in assuming that there was no administrative boundary for
> Pine Valley.)
> >
> maybe but i would do some more research before making an assumption.
> i'm aware of many postal city addresses that are in different counties
> than the
> "real" cities and i believe there are at least 4 cases where postal
> delivery
> crosses state lines.
>
> richard
>
> --
> rwe...@averillpark.net
>  Averill Park Networking - GIS & IT Consulting
>  OpenStreetMap - PostgreSQL - Linux
>  Java - Web Applications - Search
>
>
>
> ___
> 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: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Jérôme Seigneuret]

Le 9 novembre 2015 16:58, Philippe Verdy  a écrit :

> Le 9 novembre 2015 16:12, Jérôme Seigneuret  a
> écrit :
>
>> C'est implémenté dans les langages. C'est le principe de passage forcé
>> d'un centenaire avec deux caractères vers 4 caractères YYto
>>
>> Donc C11 renvoi vers 1100-1199 (équivalent OSM 1100..1199)
>>
>
> Ce qui est le **12e** siècle et pas le 11e ! Piège courant (aussi bien en
> anglais qu'en français d'ailleurs). On est aujourd'hui au 21e siècle, pas
> au 20e même si les deux premiers chiffres de l'année commencent par 20, les
> siècles sont comptés à partir de 1, il n'y a pas de siècle zéro !
>

En effet donc dans mon cas c'est C10

>
> mais on peut aussi faire C1150 qui renvoi 1150-1249
>> (équivalent OSM 1150..1249)
>>
>
> Encore plus "merdique", car C11 désigne un siècle (lequel??) mais C1150
> désigne une année de départ, quid alors du siècle débutant en année 11, il
> faut l'écrire alors C0011 ?
>

Exact en tous cas c'est comme ça que le code le prévois


>
> Pour les préfixes c'est interne à OSM comme ~ et autres. Ca mérite à être
>> simplifié ou à proposer des correspondances d'écritures
>>
>> Le but étant de gérer uniformément l'incertitude
>>
>
> Oui pour que ce soit uniforme, mais alors réfléchir à quelquechose de
> cohérent. Le message de départ donnait le 11è siècle, mais là tu as répondu
> avec le 12è !
>
Je suis d'accord merci pour cette correction


>
> Bref comme d'habitude, les tags sous OSM sont créés à la volée, on en
> discute après et ensuite on essaye d'uniformiser et on sse rend compte que
> tout le monde ne comprend pas le même langage. Le minimum serait de
> documenter même les essais sur le wiki afin de pouvoir les critiquer et
> ensuite trouver des solutions d'uniformisation et de migration, puis
> réparer tout ça dans la base car à la longue ces tags multiples compliquent
> les applications de tout le monde.
>
> Je ne dis pas le contraire. Mais mieux vaut le faire maintenant que quand
ce sera déjà utilisé par 5 contributeurs avec des méthodes différentes


> Quitte à faire simple et non ambigu, il serait préférable de mentionner un
> intervalle entre deux dates au format ISO8601 (année, année-mois, ou
> année-mois-jour) et ne pas avoir à se soucier des unités. La première
> réponse était plus simplet et au moins non ambigue le 11e siècle était
> historic:century=11
>

Oui mais finalement on sort du schéma pour créer une nouvelle clé...


> Note, on a aussi besoin d'intervalles pour des périodes de construction
> avec pour les deux bornes des intertitudes. L'usage pour les intervalles
> c'est d'utiliser le signe " - " encadré d'espaces pour ne pas entrer en
> conflit avec le "-" accollé sans espace entre les éléménts d'une date ISO
> 8601. Il donc faut un autre séparateur pour les marges d'intertitude.
>
> Si on voulait préciser une construction s'étalant du 11e siècle au 15e,
> cela donnerait "1001..1099 - 1401..1499". Si on peut dater plus précisément
> une date, par exemple février 1492 pour la seconde borne au lieu du simple
> 15e siècle, cela donnerait "1001..1099 - 1492-02"
>
> Je trouve ça plutôt intéressant


> Mais si la construction s'est achevée encore plus précisément le 12 ou le
> 13 février, cela donnerait "1001..1099 - 1492-02-12..1492-02-13" (les 4
> dates mentionnée sont toutes en format compatible ISO 8601 (lequel format
> n'inclut aucune espace ni aucun point... mais admet qu'on puisse supprimer
> les séparateurs "-" entre les composants année-mois-jour à condition de
> mettre les années sur 4 chiffres minimum, donc autoriserait aussi qu'on
> utilise pour nos intervalles: ""1001..1099 - 14920212..14920213").
>
Moi ça me va

>
> Autre difficulté: les siècles avant Jesus-Christ (important pour dater le
> patrimoine historique). Par convention on suit la date de "BC" en anglais,
> toujours en fin de date donc après l'indication éventuelle du mois et du
> jour, pas entre l'année et le mois. Mais là aussi on n'a alors pas d'année
> "zéro" dans les calendriers, l'année qui précède l'année 0001 est alors
> l'année 0001BC mais en notation astronomique cette année est désignée
> "" et les années précédentes sont décalées de 1 par rapport aux année
> calendaires, en utilisant un signe "-" avant l'année, donc "-0001" désigne
> "0002BC". Les années après Jesus-Christ sont dans l'ère "AD" masi il n'est
> pas utile de l'indiquer si on veut garder la compatibilité ISO 8601 des
> dates d'aujourd'hui où aucun suffixe d'ère n'est nécessaire pour l'actuel
> calendrier grégorien.
>

Bref, il y a du taf. On commence par quoi?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

[Jérôme Seigneuret]

Bonjour,
Le nom de la résidence se met par usage sur le landuse. Il faut découper le
landuse existant pour éviter les superpositions de landuse.

Le nom du bâtiment sur building

Jérôme

Le 9 novembre 2015 19:39, Julien Noblet  a écrit :

> Bonjour,
> Je viens vers vous pour savoir comment taguer une résidence ou une cité de
> plusieurs bâtiments.
> J'avais pensé à une relation de "type"="site"
> name=
> Avec un chemin avec un rôle perimeter, et les bâtiments avec un rôle
> building.
> Chaque bâtiment peut avoir un nom (ou plutôt une ref) name/ref = Bâtiment
> A/B/C/D...
>
> Quels tags devraient être ajoutés la relation?
>
> Est-ce que j'ai tout faux et je devrais utiliser sur les bâtiment un
> addr:place ou addr:X=?
>
> Merci par avance.
> Librement.
>
> Julien_N
>
> ___
> 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-latam] OSM en la cumple Open Government Partnership- Eventos abiertos #ogpmapping

[Javier Carranza]

Hola compas maperos!

En seguimiento a la invitación y aviso que antes hiciera la compañera
Miriam González , querìa hacer devolución contándoles algo de lo que
hicimos en México a fines del mes pasado.

OpenStreetMap MX y US, Development Seed , Mapbox , Mapzen y Telenav nos
invitaron como comunidad GeoCensos

a organizar juntos en la cumbre del gobierno abierto la #mappingrevolution
 ; un total de 6
eventos , incluyendo una
sesión de speed geek  llamada #GeoData4Stats
 y
una sesión de mapathon  . En total alrededor de
300 personas
se registraron en estos eventos, muchos de los cuales habían estado el año
pasado en ConMapas . Si les interesa les
podemos hacer llegar el material que presentamos.

Como parte del ecosistema , y después de éstas y otras contribuciones
temáticas en varias conferencias de geo datos abiertos
 este año fuimos invitados a asistir como sociedad
 civil a la Conferencia Estadística de las Américas
 . Nos estamos preparando para hacer escuchar
una declaración sobre·revolución mapera de datos en ese evento. Sin
embargo, nos gustaría invitar a sumar a todas las comunidades OSM y
presentarnos unidos en un formato colectivo para poder promover
entre  representantes de Oficinas Nacionales de Estadística de la región
una buena actitud hacia la revolución datera y hacia toda la comunidad
mapera sin restricciones.

Por recomendación de Mikel
,
les propongo aprovechar juntos esta iniciativa y discutir juntos
una declaración que estamos preparando para hacérsela llegar a los
institutos de estadística para que nos abran sus datos , ¿que les parece?

Gracias desde ya por su apoyo.

[image: geocensos]
*Javier Carranza** Tresoldi** CEO**, GeoCensos*
Tel: (571) 806-5188
Skype: javiercarranza

Peru Mobile: (51) 994836360
El Salvador Mobile: (503) 61150333
Colombia Mobile:(57) 314-3244540
Panama Mobile: (507) 688 - 04892
Guatemala Mobile: (502) 5936 - 0180
www.geocensos.com
*Lets map together a better world*
 [image: Twitter]
 [image: LinkedIn]


"La información aquí contenida es para uso exclusivo de la persona o
entidad de destino. Está estrictamente prohibida su utilización, copia,
descarga, distribución, modificación y/o reproducción total o parcial, sin
el permiso expreso del representante legal de Fundación Geocensos, pues su
contenido puede ser de carácter confidencial y/o contener material
privilegiado. Si usted recibió esta información por error, por favor
contacte en forma inmediata a quien la envió y borre este material de su
computador. La Fundación GeoCensos no es responsable por la información
contenida en esta comunicación, el directo responsable es quien la firma o
el autor de la misma."

2015-10-26 20:32 GMT-05:00 Gonzales, Miriam - (p) :

> Hola a toda la comunidad OpenStreetMap MX y LatAm,
>
>  Esta semana se está llevando a cabo la cumbre Open Government Partnership
> en nuestro país donde 66 países están invitados a tomar parte de las
> iniciativas de tener Gobiernos que respondan a las necesidades de la
> ciudadanía y compartan Datos que ayuden a generar transparencia en las
> instituciones entre muchos otros objetivos. Se estarán llevando a cabo
> conferencias de Recursos Naturales, Tecnología, Open Data, Democracia entre
> muchos otros temas. Los registros ya están cerrados pero las conferencias
> en los espacios principales serán transmitidas en línea (links por
> confirmar).
>
> La comunidad internacional OpenStreetMap estará presente con integrantes
> como Alyssa Wright, Alex Barth, Javier Carranza, Steve Coast, Ian Schuler y
> varios más. Ellos estarán encargados de compartir el mensaje de Open Geo a
> una audiencia internacional comprometida con Datos Abiertos. Tendremos dos
> eventos abiertos:
>
> · Martes 27 de Octubre 2015 12pm
>
> Mapeando alrededor del Palacio de Minería, nos vemos a las 12pm en la
> entrada del Palacio
>
> Con Alex Barth @lxbarth y Miriam González @mapanauta
>
> · Miércoles 28 de Octubre 2015 7pm
>
> Open Mapping Happy Hour
>
> Roof Downtown Hotel
>
> Favor de reservar en el sitio debido a que existe un límite de espacio
> http://openmapping.splashthat.com
>
>
>
> Síguenos en Twitter con el hashtag #OGPmapping
>
> Saludos y gracias
>
> Nos vemos pronto
>
> Miriam González
>
> @mapanauta
>
>
>
>
>
> ___
> talk-latam mailing list
> talk-latam@openstreetmap.org
> 

Re: [Talk-it] Livelli amministrativi in wtoosm

[Simone F.]

Il giorno 6 novembre 2015 19:31, Simone F.  ha scritto:

> Il giorno 4 novembre 2015 21:52, Paolo Monegato 
> ha scritto:
>
>>
>>
> Magari aggiungendo anche il sottotemplate Divisione
>> amministrativa/Voci/ITA si riescono ad eliminare.
>>
> 
> Sembra funzioni ma non ho ancora controllato se si perda qualcosa.
>

Ho controllato, si perdono articoli importanti presenti solo in "Divisione
amministrativa".

La soluzione migliore mi sembra questa:
"Categoria:Regioni d'Italia" + "Template:Divisione amministrativa" +
"Template:DivAmm/ITA"

Lista di articoli:
https://dl.dropboxusercontent.com/u/41550819/OSM/WTOSM/Regioni_d%27Italia_divisione_amministrativa_divammita.zip


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

Re: [Talk-it] La mappa di OSM ha un nuovo schema colori

[Luca Delucchi]

2015-11-09 16:53 GMT+01:00 Martin Koppenhoefer :
>
>
> A prescindere del mio stile, potremmo clonare lo stato attuale di carto.
>

io ho fatto così per uno sull'escursionismo che sto realizzando ora...
qualche ora di lavoro e si riesce già ad avere qualcosa di buono e
diverso da quello attuale

> ciao,
> Martin
>

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

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

[OSM-talk-fr] Parking/Aire de covoiturage

[Gautier]

Bonsoir,

Je me permet de copier une question que j'ai posé sur le forum 
(http://forum.openstreetmap.fr/viewtopic.php?f=2=2338=9737#p9737), 
en espérant qu'une solution soit trouvée :


Il existe de plus en plus de parkings dédiés au covoiturage, mais je 
n'ai rien trouvé pour cartographier ces éléments proprement. Le plus 
proche serait d'utiliser amenity=car_sharing 
 mais 
ce n'est pas du covoiturage à proprement parler.
La plupart des parkings de covoiturage sont de simples parkings avec 
name=Aire de covoiturage ou name=Parking de covoiturage. Peut-on faire 
mieux ?


Nicolas Dumoulin, sur le forum, m'a proposé la solution 
http://www.openstreetmap.org/way/128277712 à savoir :


- amenity=parking
- carpool=designated
- name=Aire de covoiturage
- park_ride=yes

Qu'en pensez-vous ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Jérôme Seigneuret]

Bien. On va essayer déjà de faire ça en français et faire une propos
ensuite sur le wiki comme discussion en anglais mais on est déjà à un
premier niveau de réflexion sur la liste.

A voir donc :
- les besoins et les propositions possibles.
- les équivalences
- quel schéma est :

   - plus flexible et permet de traiter le plus de cas,
   - plus simple pour les contributeurs ou un outil permettant d'avoir
   quelque chose de semi-auto dixit opening_hours

- comment éviter les concurrences



Le 9 novembre 2015 18:16, Philippe Verdy  a écrit :

> On commence par en discuter en cherchant les différentes solutions et
> difficultés. Tout cela devrait être sur le wiki en vue d'une révision des
> schémas de clé.
> Mais comme d'habitude, les clés sont introduites expérimentalement par
> quelques uns, et ensuite on discute de la façon de fusionner les
> différentes idées. Après vient la question du nettoyage car on ne peut pas
> tout garder dans les applis.
> En attendant les clés non discutées, trop nombreuses, insuffisamment
> réfléchies, polluent la base et n'ont d'intérêt qu'e de façon informative à
> condition de chercher comment les interpréter humainement, on est loin de
> pouvoir automatiser les traitements, mais là en plus on ne peuyt même pas
> dire qu'il s'agit d'erreurs. Tout cela n'est qu'expérimental mais
> malheureusement sans discussion ouverte.
> Note: cette liste francophone ne suffit pas. D'une façon ou d'une autre il
> faut rendre ça visible sur le wiki et tenter des traductions anglaises même
> maladroites pour pouvoir en débattre au plan international.
> Mais la difficulté se corse quand dans un pays donné il y a eu des imports
> massifs avec des nouvelles clés ou codifications de valeurs choisies
> indépendamment de tout ce qui se fait ailleurs et sans même chercher à
> s'appuyer sur des normes connues (comme ici l'ISO 8601 ou les convetions
> CLDR ou des nomenclatures internationales existantes, ou quand les clés
> sont choisies de façon très paresseuse et entrent en conflit avec d'autres
> parce qu'aucune recherche n'a été faite avant de les utiliser pour autre
> chose)
>
> Le 9 novembre 2015 17:10, Jérôme Seigneuret  a
> écrit :
>
>>
>>
>> Le 9 novembre 2015 16:58, Philippe Verdy  a écrit :
>>
>>> Le 9 novembre 2015 16:12, Jérôme Seigneuret 
>>> a écrit :
>>>
 C'est implémenté dans les langages. C'est le principe de passage forcé
 d'un centenaire avec deux caractères vers 4 caractères YYto

 Donc C11 renvoi vers 1100-1199 (équivalent OSM 1100..1199)

>>>
>>> Ce qui est le **12e** siècle et pas le 11e ! Piège courant (aussi bien
>>> en anglais qu'en français d'ailleurs). On est aujourd'hui au 21e siècle,
>>> pas au 20e même si les deux premiers chiffres de l'année commencent par 20,
>>> les siècles sont comptés à partir de 1, il n'y a pas de siècle zéro !
>>>
>>
>> En effet donc dans mon cas c'est C10
>>
>>>
>>> mais on peut aussi faire C1150 qui renvoi 1150-1249
 (équivalent OSM 1150..1249)

>>>
>>> Encore plus "merdique", car C11 désigne un siècle (lequel??) mais C1150
>>> désigne une année de départ, quid alors du siècle débutant en année 11, il
>>> faut l'écrire alors C0011 ?
>>>
>>
>> Exact en tous cas c'est comme ça que le code le prévois
>>
>>
>>>
>>> Pour les préfixes c'est interne à OSM comme ~ et autres. Ca mérite à
 être simplifié ou à proposer des correspondances d'écritures

 Le but étant de gérer uniformément l'incertitude

>>>
>>> Oui pour que ce soit uniforme, mais alors réfléchir à quelquechose de
>>> cohérent. Le message de départ donnait le 11è siècle, mais là tu as répondu
>>> avec le 12è !
>>>
>> Je suis d'accord merci pour cette correction
>>
>>
>>>
>>> Bref comme d'habitude, les tags sous OSM sont créés à la volée, on en
>>> discute après et ensuite on essaye d'uniformiser et on sse rend compte que
>>> tout le monde ne comprend pas le même langage. Le minimum serait de
>>> documenter même les essais sur le wiki afin de pouvoir les critiquer et
>>> ensuite trouver des solutions d'uniformisation et de migration, puis
>>> réparer tout ça dans la base car à la longue ces tags multiples compliquent
>>> les applications de tout le monde.
>>>
>>> Je ne dis pas le contraire. Mais mieux vaut le faire maintenant que
>> quand ce sera déjà utilisé par 5 contributeurs avec des méthodes
>> différentes
>>
>>
>>> Quitte à faire simple et non ambigu, il serait préférable de mentionner
>>> un intervalle entre deux dates au format ISO8601 (année, année-mois, ou
>>> année-mois-jour) et ne pas avoir à se soucier des unités. La première
>>> réponse était plus simplet et au moins non ambigue le 11e siècle était
>>> historic:century=11
>>>
>>
>> Oui mais finalement on sort du schéma pour créer une nouvelle clé...
>>
>>
>>> Note, on a aussi besoin d'intervalles pour des périodes de construction
>>> avec pour les deux bornes des intertitudes. L'usage 

Re: [Talk-it] La mappa di OSM ha un nuovo schema colori

[Lorenzo Perone]

Ciao,
magari possiamo condividere su git-hub, io avevo fatto stile notturno per
mapsforge :)
Lorenzo

Il giorno lun 9 nov 2015, 19:41 Luca Delucchi  ha
scritto:

> 2015-11-09 16:53 GMT+01:00 Martin Koppenhoefer :
> >
> >
> > A prescindere del mio stile, potremmo clonare lo stato attuale di carto.
> >
>
> io ho fatto così per uno sull'escursionismo che sto realizzando ora...
> qualche ora di lavoro e si riesce già ad avere qualcosa di buono e
> diverso da quello attuale
>
> > ciao,
> > Martin
> >
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
-- 

Lorenzo

Scusa per la brevità, sto scrivendo da mobile.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[bernard]

Bonjour,
Je viens de remarquer que les couleurs de la page de téléchargement de 
JOSM ont changé.

Les Primary prennent la couleur des secondary
Les Secondary celles des Tertiary
Les Tertiary n'en a plus.
Je n'ai touché à aucun réglage

Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de 
dialogue qui nécessite un clic ... inutile.

Pour quelle raison cette modification?
Bonne soirée et merci pour vos réponses


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

[OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

[Julien Noblet]

Bonjour,
Je viens vers vous pour savoir comment taguer une résidence ou une cité de
plusieurs bâtiments.
J'avais pensé à une relation de "type"="site"
name=
Avec un chemin avec un rôle perimeter, et les bâtiments avec un rôle
building.
Chaque bâtiment peut avoir un nom (ou plutôt une ref) name/ref = Bâtiment
A/B/C/D...

Quels tags devraient être ajoutés la relation?

Est-ce que j'ai tout faux et je devrais utiliser sur les bâtiment un
addr:place ou addr:X=?

Merci par avance.
Librement.

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

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Jérôme Seigneuret]

C'est implémenté dans les langages. C'est le principe de passage forcé d'un
centenaire avec deux caractères vers 4 caractères YYto

Donc C11 renvoi vers 1100-1199 (équivalent OSM 1100..1199)
mais on peut aussi faire C1150 qui renvoi 1150-1249
(équivalent OSM 1150..1249)

Pour les préfixes c'est interne à OSM comme ~ et autres. Ca mérite à être
simplifié ou à proposer des correspondances d'écritures

Le but étant de gérer uniformément l'incertitude


Le 9 novembre 2015 15:46, dHuy Pierre  a écrit :

> Je ne pense pas que ça soit ISO effectivement mais largement utilisé et
> documenté sur le Wiki, sur le lien fourni plus haut d'ailleurs. Les
> logiciels comme josm renvoie d'ailleurs à cette page pour ce type de clef
> donc c'est plutôt largement utilisé. Et puis c'est toujours mieux que
> d'ajouter un tag qui ne sera utilisé que par peu de personnes.
>
>
>
> Le Lundi 9 novembre 2015 15h31, Philippe Verdy  a
> écrit :
>
>
> La syntaxe avec C11 est-elle bien supportée et compatible avec l'ISO ou un
> format RFC connu pour les dates? En tout cas celle avec tilde ou avec un
> mot clé supplémentaire comme "mid" n'est documentée nulle part. Pour
> l'instant start_daye n'est documentée qu'avec une date précise jusqu'à la
> seconde,  mais au minimum avec l'année complète et rien pour les autres
> intervalles d'incertitude.
> Le 9 nov. 2015 13:50, "dHuy Pierre"  a écrit :
>
> Il y aussi start_date=C11 ou ~C11 ou même mid C11 pour le milieu du siècle
> qui correspond très bien plutôt que d'inventer un nouveau tag.
>
>
>
> Le Lundi 9 novembre 2015 11h21, Philippe Verdy  a
> écrit :
>
>
> tu peux proposer "historic:century=11" si la classification par époque ou
> civilisation est difficile (d'ailleurs elle varie selon les pays ou
> cultures, ce qui est documenté est difficile à standardiser et faire
> accepter partout).
> le "start_date=*" est plutôt réservé à noter des dates précises (avec un
> format compatible ISO 8601 contenant au minimum une année complète), mais
> le XIe siècle n'est pas assez précis on ne peut pas non plus mettre
> "start_date=1001-1100" (format incompatible posant problème),
> start_date=1001 (oui, le XIe siècle commence l'année suivant l'an mil) ou
> start_date=1050 (milieu du siècle) serait au contraire trop précis (rien
> n'indique que c'est en fait une estimation à plus ou mois 50 ans près).
>
> Le 9 novembre 2015 11:07, Jérôme Seigneuret  a
> écrit :
>
> Bonjour, en faisant un fix sur le nom d'une église je me retrouve à avoir:
> Église ST Barthélémy XIième siècle que je corrige en Église
> Saint-Barthélémy-de-Baillarguet
>
> Mon problème est d'ajouter l'information lié au XI ème siècle
> > période du moyen age central + précision sur le siècle
>
> Ducoup je regarde du coté des tags
> http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilization
> historic:period =
> start_date =
>
> Je me rend compte que rien n'est précisé sur les siècles tel que l'on a
> l'habitude de l'utilisé d'une part et que les grandes périodes de notre
> civilisation ne sont pas détaillé:
> préhistoire et protohistoire c'est OK
>
>- *historic:civilization*=prehistoric
>- *historic:civilization*=protohistoric
>
>
> Reste les périodes après JC et les périodes spécifique à des régions
>
> moyen-age :vie ‑xve
>
> haut Moyen Âge = : vie ‑ xe siècle
> Moyen Âge central : xie ‑ xiiie siècle
> Moyen Âge tardif  :
> xive ‑ xve siècle
>
>
> époque moderne :
>
> Époque moderne antérieure :1492 – 1792
>
> époque contemporaine :
>
> Époque moderne I : 1792 – 1920
> Époque moderne II : 1920 à nos jours
>
>
> Bonne journée
> Jérôme
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> ___
> 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-us] Proposal: Sunset ref=* on ways in, favor of relations

[Richard Welty]

On 11/9/15 10:32 AM, Richard Fairhurst wrote:
> Richard Welty wrote:
>> the key thing, i think, is that mappers have little motivation to 
>> work on route relations if they don't actually get used by 
>> anything.
> Don't forget that the issue is not an endemic issue with route relations,
> it's just an osm2pgsql issue.
>
> osm2pgsql is the most popular tool for loading data into a database for
> raster rendering. But it's not the only one; that's not the only use case
> for OSM data; and who knows whether osm2pgsql will remain pivotal as vector
> rendering supersedes raster rendering. I use Interstate route relations as a
> small part of cycle.travel's routing algorithm, for example. "Anything" is a
> big word!
this is all true. but most mappers have no visibility into alternate
data consumers that might use the data. an alternate rendering
demonstrating visible use of route relations might make all the difference
in the world.

paul's comment in github is true, there is a huge amount of work to be
done with US route relations. if we want to think of the rendering on
openstreetmap.org as our "production" rendering then route relations are
not ready and won't be for a very very long, if ever. so i think we should
at least start talking about an alternate rendering derived from Phil's work
at a suitable location. i'm completely swamped with teaching and with
the work i'm doing for the NTF right now, but the latter at some point will
ease up (i hope) and i should be able to pitch in.
richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




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

Re: [Talk-us] Importing Buildings and Addresses for Austin, Texas

[Eric Ladner]

Were steps taken to remove pre-existing buildings in OSM from the imported
data set?  As an example, see [1].

Looking at the data in the area, this seems the case, but I didn't
exhaustively search through all the files.  Replacing existing hand drawn
buildings with imports from the city's GIS system would probably be
preferable given the quality of the hand drawn buildings.  (compare the
outline in [1] to satellite imagery).

[1] http://www.openstreetmap.org/way/28570675


On Mon, Nov 9, 2015 at 8:13 AM Andy Wilson 
wrote:

> We would would like to import buildings and addresses for Austin, Texas
> and surrounding areas. Our plan on the OSM wiki:
> https://wiki.openstreetmap.org/wiki/Austin,_TX/Buildings_Import
> Processed data files for import can be found here:
> https://github.com/wilsaj/atx-buildings/tree/with-import-data/osm
>
> I should note that we had a bit of a false start on import the today. I
> thought we were ok to begin the import, but we were asked to stop. This is
> my fault; I misunderstood the import review process. We are now paused and
> awaiting feedback and approval from this list before continuing.
>
> If you could find time to look things over, we would really appreciate it.
>
> Thanks!
> ___
> 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

[OSM-talk] WG: Undiscussed (?) edits removing lesser-used highway=* tags

[Gerd Petermann]

I just noticed that I forgot to set the list on cc, see below.


Gerd


Von: Gerd Petermann
Gesendet: Montag, 9. November 2015 10:03
An: Martin Koppenhoefer
Betreff: AW: [OSM-talk] Undiscussed (?) edits removing lesser-used highway=* 
tags


"a link "links" (connects) two different roads"

yes, but that is more or less the case with all roads, isn't it? So why do we

have tags like "highway=trunk_link" instead of a combination like e.g.

"highway=trunk"

"link=yes" ?

Maybe it is just a historical convinience  (I'd call it error then) which

nobody dared to change ?


Gerd


Von: Martin Koppenhoefer 
Gesendet: Montag, 9. November 2015 09:44
An: GerdP
Cc: osm
Betreff: Re: [OSM-talk] Undiscussed (?) edits removing lesser-used highway=* 
tags


2015-11-09 7:39 GMT+01:00 GerdP 
>:
I only know a discussion in Germany which came to the
conclusion that tags like unclassified_link, residential_link and
service_link make not much sense:
http://forum.openstreetmap.org/viewtopic.php?id=26083
The wiki doesn't mention those _link types as well, and my
understanding is that only major roads have a link (if link
in english means what we call "Abfahrt/ Auffahrt" in Germany,
I would describe it as a lane that allows to decrease/increase
speed.


literally, a link "links" (connects) two different roads. While I agree that 
for service roads this seems a strange tag, I could imagine unclassified and 
residential links to make sense somehow (at roundabouts), but personally I'm 
using the main road class (i.e. unclassified or residential) for these "links".

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

[OSRM-talk] A friend just gave you $10 to try DigitalOcean

[DigitalOcean]

Subject Line (for proofing, doesn't show in actual email)
 == Deploy a Server
For Free! ==

  Your friend gmjun2000 has been using DigitalOcean – a cloud hosting
service designed just for developers – and thought you might want to give
it a shot. You can deploy a server in 55 seconds from our control panel or
use our simple API.

 Because you’ve been invited by a friend, we’d like to give you a $10
credit to try it out. Just use this link to create an account and you’ll
be credited automatically.

 Redeem Your Credit


  Happy Coding,
 DigitalOcean

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

[Talk-it-trentino] toponomastica a Trento in Trentino

[Maurizio Napolitano]

Ciao
su richiesta di una amica ho sviluppato una mappa che mostra le strade
dedicate a uomini e donne sul comune di Trento.
http://labmod.org/maps/dudesmaptrento/#14/46.0641/11.1322

Inizialmente sono partito dai dati di openstreetmap, ma poi mi sono
accorto che alcune voci erano obsolete.
Ho così riguardato tutto e, di fatto, ho messo mano a quasi tutte le
strade della città.
Più che altro ho inserito i nomi di battesimo delle persone a cui le
vie sono state dedicate e messo i nomi alle vie senza nome (in
particolare quelle dei sobborghi).
Le modifiche sono state diverse.

Vi invito pertanto a dare un occhio alle zone che conoscete per vedere
se qualcosa è cambiato.
Ad esempio, su Trento, molti parchi pubblici hanno cambiato nome (es.
giardini Santa Chiara ora si chiama Aleksandr Solzenicyn) e alcune
strade sono state "divise" per dare un nuovo nome al tratto definito.
In alcuni casi (es. i parchi) ho inserito il nome precedente come
"alt_name" sia perchè non tutti i cartelli che ho visto in giro per
Trento sono stati aggiornati, sia perchè le persone continuano ad
usare il vecchio nome.

... spero piuttosto di non aver fatto danni :)

bye


-- 
Maurizio "Napo" Napolitano
http://de.straba.us

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

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Philippe Verdy]

Le 9 novembre 2015 16:12, Jérôme Seigneuret  a
écrit :

> C'est implémenté dans les langages. C'est le principe de passage forcé
> d'un centenaire avec deux caractères vers 4 caractères YYto
>
> Donc C11 renvoi vers 1100-1199 (équivalent OSM 1100..1199)
>

Ce qui est le **12e** siècle et pas le 11e ! Piège courant (aussi bien en
anglais qu'en français d'ailleurs). On est aujourd'hui au 21e siècle, pas
au 20e même si les deux premiers chiffres de l'année commencent par 20, les
siècles sont comptés à partir de 1, il n'y a pas de siècle zéro !

mais on peut aussi faire C1150 qui renvoi 1150-1249
> (équivalent OSM 1150..1249)
>

Encore plus "merdique", car C11 désigne un siècle (lequel??) mais C1150
désigne une année de départ, quid alors du siècle débutant en année 11, il
faut l'écrire alors C0011 ?

Pour les préfixes c'est interne à OSM comme ~ et autres. Ca mérite à être
> simplifié ou à proposer des correspondances d'écritures
>
> Le but étant de gérer uniformément l'incertitude
>

Oui pour que ce soit uniforme, mais alors réfléchir à quelquechose de
cohérent. Le message de départ donnait le 11è siècle, mais là tu as répondu
avec le 12è !

Bref comme d'habitude, les tags sous OSM sont créés à la volée, on en
discute après et ensuite on essaye d'uniformiser et on sse rend compte que
tout le monde ne comprend pas le même langage. Le minimum serait de
documenter même les essais sur le wiki afin de pouvoir les critiquer et
ensuite trouver des solutions d'uniformisation et de migration, puis
réparer tout ça dans la base car à la longue ces tags multiples compliquent
les applications de tout le monde.

Quitte à faire simple et non ambigu, il serait préférable de mentionner un
intervalle entre deux dates au format ISO8601 (année, année-mois, ou
année-mois-jour) et ne pas avoir à se soucier des unités. La première
réponse était plus simplet et au moins non ambigue le 11e siècle était
historic:century=11

Note, on a aussi besoin d'intervalles pour des périodes de construction
avec pour les deux bornes des intertitudes. L'usage pour les intervalles
c'est d'utiliser le signe " - " encadré d'espaces pour ne pas entrer en
conflit avec le "-" accollé sans espace entre les éléménts d'une date ISO
8601. Il donc faut un autre séparateur pour les marges d'intertitude.

Si on voulait préciser une construction s'étalant du 11e siècle au 15e,
cela donnerait "1001..1099 - 1401..1499". Si on peut dater plus précisément
une date, par exemple février 1492 pour la seconde borne au lieu du simple
15e siècle, cela donnerait "1001..1099 - 1492-02"

Mais si la construction s'est achevée encore plus précisément le 12 ou le
13 février, cela donnerait "1001..1099 - 1492-02-12..1492-02-13" (les 4
dates mentionnée sont toutes en format compatible ISO 8601 (lequel format
n'inclut aucune espace ni aucun point... mais admet qu'on puisse supprimer
les séparateurs "-" entre les composants année-mois-jour à condition de
mettre les années sur 4 chiffres minimum, donc autoriserait aussi qu'on
utilise pour nos intervalles: ""1001..1099 - 14920212..14920213").

Autre difficulté: les siècles avant Jesus-Christ (important pour dater le
patrimoine historique). Par convention on suit la date de "BC" en anglais,
toujours en fin de date donc après l'indication éventuelle du mois et du
jour, pas entre l'année et le mois. Mais là aussi on n'a alors pas d'année
"zéro" dans les calendriers, l'année qui précède l'année 0001 est alors
l'année 0001BC mais en notation astronomique cette année est désignée
"" et les années précédentes sont décalées de 1 par rapport aux année
calendaires, en utilisant un signe "-" avant l'année, donc "-0001" désigne
"0002BC". Les années après Jesus-Christ sont dans l'ère "AD" masi il n'est
pas utile de l'indiquer si on veut garder la compatibilité ISO 8601 des
dates d'aujourd'hui où aucun suffixe d'ère n'est nécessaire pour l'actuel
calendrier grégorien.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Prapodivná trasa

[Matěj Cepl]

On 2015-11-09, 11:02 GMT, Marián Kyral wrote:
> Ten problém je o tom, že router preferuje průjezd přes co 
> nejméně hranic I za cenu docela velké zajížďky. Zřejmě právě 
> na přechodu státních hranic počítá s časem navíc.

No tak poučit algoritmus o existenci Shengenského prostoru je 
sice case-specific, ale možná by to nebylo nic tak nemravného. 

if hranice in shengen_hranice:
penalty = 0.01
else
penalty = 1000

:) nebo něco podobného ...

Když jsme se z toho Německa vraceli, tak jsme se téměř nedobrali 
toho, jestli jsme u Žitavy přejeli také přes Polsko nebo ne ;).

Matěj

-- 
http://www.ceplovi.cz/matej/, Jabber: mc...@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
SCSI is *not* magic. There are *fundamental* *technical*
reasons why you have to sacrifice a young goat to your SCSI
chain every now and then.
-- John F. Woods


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

Re: [Talk-it-trentino] toponomastica a Trento in Trentino

[Paolo Ianes]

Che lavorone che hai fatto Napo!
Forse tra via Belenzani e Via delle Orfane si potrebbe inserire Galleria
degli Scudai che porta da Via Belenzani in Piazzetta Padre Diego Lainez e
ques'ultima.
Di fianco c'è Vicolo Colico che credo sia intestato alla famiglia Colico e
non ad una singola persona.

A presto

Paolo

Il giorno 9 novembre 2015 16:48, Maurizio Napolitano 
ha scritto:

> Ciao
> su richiesta di una amica ho sviluppato una mappa che mostra le strade
> dedicate a uomini e donne sul comune di Trento.
> http://labmod.org/maps/dudesmaptrento/#14/46.0641/11.1322
>
> Inizialmente sono partito dai dati di openstreetmap, ma poi mi sono
> accorto che alcune voci erano obsolete.
> Ho così riguardato tutto e, di fatto, ho messo mano a quasi tutte le
> strade della città.
> Più che altro ho inserito i nomi di battesimo delle persone a cui le
> vie sono state dedicate e messo i nomi alle vie senza nome (in
> particolare quelle dei sobborghi).
> Le modifiche sono state diverse.
>
> Vi invito pertanto a dare un occhio alle zone che conoscete per vedere
> se qualcosa è cambiato.
> Ad esempio, su Trento, molti parchi pubblici hanno cambiato nome (es.
> giardini Santa Chiara ora si chiama Aleksandr Solzenicyn) e alcune
> strade sono state "divise" per dare un nuovo nome al tratto definito.
> In alcuni casi (es. i parchi) ho inserito il nome precedente come
> "alt_name" sia perchè non tutti i cartelli che ho visto in giro per
> Trento sono stati aggiornati, sia perchè le persone continuano ad
> usare il vecchio nome.
>
> ... spero piuttosto di non aver fatto danni :)
>
> bye
>
>
> --
> Maurizio "Napo" Napolitano
> http://de.straba.us
>
> ___
> Talk-it-trentino mailing list
> Talk-it-trentino@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-trentino
>
___
Talk-it-trentino mailing list
Talk-it-trentino@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-trentino

Re: [Talk-us] Proposal: Sunset ref=* on ways in, favor of relations

[Richard Fairhurst]

Richard Welty wrote:
> the key thing, i think, is that mappers have little motivation to 
> work on route relations if they don't actually get used by 
> anything.

Don't forget that the issue is not an endemic issue with route relations,
it's just an osm2pgsql issue.

osm2pgsql is the most popular tool for loading data into a database for
raster rendering. But it's not the only one; that's not the only use case
for OSM data; and who knows whether osm2pgsql will remain pivotal as vector
rendering supersedes raster rendering. I use Interstate route relations as a
small part of cycle.travel's routing algorithm, for example. "Anything" is a
big word!

Richard




--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-Proposal-Sunset-ref-on-ways-in-favor-of-relations-tp5859312p5859503.html
Sent from the USA mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Philippe Verdy]

On commence par en discuter en cherchant les différentes solutions et
difficultés. Tout cela devrait être sur le wiki en vue d'une révision des
schémas de clé.
Mais comme d'habitude, les clés sont introduites expérimentalement par
quelques uns, et ensuite on discute de la façon de fusionner les
différentes idées. Après vient la question du nettoyage car on ne peut pas
tout garder dans les applis.
En attendant les clés non discutées, trop nombreuses, insuffisamment
réfléchies, polluent la base et n'ont d'intérêt qu'e de façon informative à
condition de chercher comment les interpréter humainement, on est loin de
pouvoir automatiser les traitements, mais là en plus on ne peuyt même pas
dire qu'il s'agit d'erreurs. Tout cela n'est qu'expérimental mais
malheureusement sans discussion ouverte.
Note: cette liste francophone ne suffit pas. D'une façon ou d'une autre il
faut rendre ça visible sur le wiki et tenter des traductions anglaises même
maladroites pour pouvoir en débattre au plan international.
Mais la difficulté se corse quand dans un pays donné il y a eu des imports
massifs avec des nouvelles clés ou codifications de valeurs choisies
indépendamment de tout ce qui se fait ailleurs et sans même chercher à
s'appuyer sur des normes connues (comme ici l'ISO 8601 ou les convetions
CLDR ou des nomenclatures internationales existantes, ou quand les clés
sont choisies de façon très paresseuse et entrent en conflit avec d'autres
parce qu'aucune recherche n'a été faite avant de les utiliser pour autre
chose)

Le 9 novembre 2015 17:10, Jérôme Seigneuret  a
écrit :

>
>
> Le 9 novembre 2015 16:58, Philippe Verdy  a écrit :
>
>> Le 9 novembre 2015 16:12, Jérôme Seigneuret  a
>> écrit :
>>
>>> C'est implémenté dans les langages. C'est le principe de passage forcé
>>> d'un centenaire avec deux caractères vers 4 caractères YYto
>>>
>>> Donc C11 renvoi vers 1100-1199 (équivalent OSM 1100..1199)
>>>
>>
>> Ce qui est le **12e** siècle et pas le 11e ! Piège courant (aussi bien en
>> anglais qu'en français d'ailleurs). On est aujourd'hui au 21e siècle, pas
>> au 20e même si les deux premiers chiffres de l'année commencent par 20, les
>> siècles sont comptés à partir de 1, il n'y a pas de siècle zéro !
>>
>
> En effet donc dans mon cas c'est C10
>
>>
>> mais on peut aussi faire C1150 qui renvoi 1150-1249
>>> (équivalent OSM 1150..1249)
>>>
>>
>> Encore plus "merdique", car C11 désigne un siècle (lequel??) mais C1150
>> désigne une année de départ, quid alors du siècle débutant en année 11, il
>> faut l'écrire alors C0011 ?
>>
>
> Exact en tous cas c'est comme ça que le code le prévois
>
>
>>
>> Pour les préfixes c'est interne à OSM comme ~ et autres. Ca mérite à être
>>> simplifié ou à proposer des correspondances d'écritures
>>>
>>> Le but étant de gérer uniformément l'incertitude
>>>
>>
>> Oui pour que ce soit uniforme, mais alors réfléchir à quelquechose de
>> cohérent. Le message de départ donnait le 11è siècle, mais là tu as répondu
>> avec le 12è !
>>
> Je suis d'accord merci pour cette correction
>
>
>>
>> Bref comme d'habitude, les tags sous OSM sont créés à la volée, on en
>> discute après et ensuite on essaye d'uniformiser et on sse rend compte que
>> tout le monde ne comprend pas le même langage. Le minimum serait de
>> documenter même les essais sur le wiki afin de pouvoir les critiquer et
>> ensuite trouver des solutions d'uniformisation et de migration, puis
>> réparer tout ça dans la base car à la longue ces tags multiples compliquent
>> les applications de tout le monde.
>>
>> Je ne dis pas le contraire. Mais mieux vaut le faire maintenant que quand
> ce sera déjà utilisé par 5 contributeurs avec des méthodes différentes
>
>
>> Quitte à faire simple et non ambigu, il serait préférable de mentionner
>> un intervalle entre deux dates au format ISO8601 (année, année-mois, ou
>> année-mois-jour) et ne pas avoir à se soucier des unités. La première
>> réponse était plus simplet et au moins non ambigue le 11e siècle était
>> historic:century=11
>>
>
> Oui mais finalement on sort du schéma pour créer une nouvelle clé...
>
>
>> Note, on a aussi besoin d'intervalles pour des périodes de construction
>> avec pour les deux bornes des intertitudes. L'usage pour les intervalles
>> c'est d'utiliser le signe " - " encadré d'espaces pour ne pas entrer en
>> conflit avec le "-" accollé sans espace entre les éléménts d'une date ISO
>> 8601. Il donc faut un autre séparateur pour les marges d'intertitude.
>>
>> Si on voulait préciser une construction s'étalant du 11e siècle au 15e,
>> cela donnerait "1001..1099 - 1401..1499". Si on peut dater plus précisément
>> une date, par exemple février 1492 pour la seconde borne au lieu du simple
>> 15e siècle, cela donnerait "1001..1099 - 1492-02"
>>
>> Je trouve ça plutôt intéressant
>
>
>> Mais si la construction s'est achevée encore plus précisément le 12 ou le
>> 13 février, cela donnerait "1001..1099 - 

Re: [OSM-talk-fr] Parking/Aire de covoiturage

[Jérôme Seigneuret]

J'en ai fait avec amenity=car_sharing mais j'avais rien trouvé à l'époque.

Voilà ma proposition:

amenity=parking (ou parking_space)
park_ride =hov
name=Aire de Covoiturage
access=hov


Le 9 novembre 2015 20:08, Gautier  a écrit :

> Bonsoir,
>
> Je me permet de copier une question que j'ai posé sur le forum (
> http://forum.openstreetmap.fr/viewtopic.php?f=2=2338=9737#p9737), en
> espérant qu'une solution soit trouvée :
>
> Il existe de plus en plus de parkings dédiés au covoiturage, mais je n'ai
> rien trouvé pour cartographier ces éléments proprement. Le plus proche
> serait d'utiliser amenity=car_sharing
>  mais ce
> n'est pas du covoiturage à proprement parler.
> La plupart des parkings de covoiturage sont de simples parkings avec
> name=Aire de covoiturage ou name=Parking de covoiturage. Peut-on faire
> mieux ?
>
> Nicolas Dumoulin, sur le forum, m'a proposé la solution
> http://www.openstreetmap.org/way/128277712 à savoir :
>
> - amenity=parking
> - carpool=designated
> - name=Aire de covoiturage
> - park_ride=yes
>
> Qu'en pensez-vous ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-gb-westmidlands] Fix oneway streets with Telenav tool

[Rob Nickerson]

Hi all,

At the end of October Telenav released a tool to help identify incorrectly
tagged, or missing, one way streets in OpenStreetMap. The *potential*
errors can be viewed at [1]
, but the
best way to use it is with the “trafficFlowDirection” plugin for JOSM.
Basic instructions at [2], full instructions at [3].

Happy mapping.
Rob

[1] http://improve-osm.org/trafficFlowDirection/#6/53.219/-2.889
[2]
http://www.mappa-mercia.org/2015/11/improve-osm-traffic-flow-direction.html
[3] https://www.openstreetmap.org/user/mvexel/diary/36244
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

[Talk-co] Invitación: El tigre en Paz Stereo lun 9 de Nov de 2015 4pm - 5pm (carlos felipe castillo)

[Carlos Felipe Castillo]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20151109T21Z
DTEND:20151109T22Z
DTSTAMP:20151109T201617Z
ORGANIZER;CN=Carlos Felipe Castillo:mailto:kaxti...@gmail.com
UID:c5nlglidjs161ntocppk9fu...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;X-NUM-GUESTS=0:mailto:arttes...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Carlos Felipe Castillo;X-NUM-GUESTS=0:mailto:kaxti...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Humberto Yances;X-NUM-GUESTS=0:mailto:hyan...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=talk-co@openstreetmap.org;X-NUM-GUESTS=0:mailto:talk-co@openstreetm
 ap.org
CREATED:20151109T201540Z
DESCRIPTION:Visualice el evento en la URL https://www.google.com/calendar/e
 vent?action=VIEW=YzVubGdsaWRqczE2MW50b2NwcGs5ZnVpdmMgdGFsay1jb0BvcGVuc3
 RyZWV0bWFwLm9yZw=MTgja2F4dGlsbG9AZ21haWwuY29tOWVjMDE5OWVkYmYzZTQwMzA3OG
 VjYjUxYjBjMzgxMTUzN2IxMjc4Yw=America/Bogota=es.
LAST-MODIFIED:20151109T201617Z
LOCATION:pazestereo.co
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:El tigre en Paz Stereo
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [OSM-talk-fr] Problème de nommage de rue

[Christian Quest]

J'irai demander confirmation à la mairie... et leur signaler l'incohérence
des panneaux ;)

Le 9 novembre 2015 13:52, Jérôme Seigneuret  a
écrit :

>
>> Dans les manuels de littérature, c'est le nom complet qui est mentionné
>> et le lien  avec la commune semble digne d'être indiqué.
>> De bonnes raisons pour éviter l'abréviation .
>>
>>
> Le choix dans OSM est clair de toute façon. Pas d’abréviation dans le name
> sinon il y a le tag short_name
>  pour cela.
> Jérôme
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

[Talk-GB] Fix oneway streets with Telenav tool

[Rob Nickerson]

Hi all,

At the end of October Telenav released a tool to help identify incorrectly
tagged, or missing, one way streets in OpenStreetMap. The *potential*
errors can be viewed at [1]
, but the
best way to use it is with the “trafficFlowDirection” plugin for JOSM.
Basic instructions at [2], full instructions at [3].

Happy mapping.
Rob

[1] http://improve-osm.org/trafficFlowDirection/#6/53.219/-2.889
[2]
http://www.mappa-mercia.org/2015/11/improve-osm-traffic-flow-direction.html
[3] https://www.openstreetmap.org/user/mvexel/diary/36244
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[Vincent de Château-Thierry]

Bonsoir,

Le 09/11/2015 21:07, Jérôme Seigneuret a écrit :

Normal que l'on ne voit pas le message initial de Bernard dans la liste?


Il est bien là : 
https://lists.openstreetmap.org/pipermail/talk-fr/2015-November/078585.html



Le 9 novembre 2015 20:59, David Crochet > a écrit :

Bonjour

Le 09/11/2015 19:39, bernard a écrit :

Bonjour,
Je viens de remarquer que les couleurs de la page de
téléchargement de
JOSM ont changé.
Les Primary prennent la couleur des secondary
Les Secondary celles des Tertiary
Les Tertiary n'en a plus.
Je n'ai touché à aucun réglage

Normal


La charte par défaut d'osm.org a changé il y a une semaine : 
https://blog.openstreetmap.org/2015/10/30/openstreetmap-org-map-changing/
C'est celle qui s'affiche aussi dans JOSM par défaut. On l'a évoqué ici 
: 
https://lists.openstreetmap.org/pipermail/talk-fr/2015-October/078440.html




Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
dialogue qui nécessite un clic ... inutile.
Pour quelle raison cette modification?


JOSM est un logiciel en constante évolution. S'il y a évolution,
c'est qu'il y a demande d'évolution.


Cette évolution fait la "une" des changements de la dernière version 
stable : https://josm.openstreetmap.de/wiki/Fr%3AStartupPage


vincent

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

Re: [OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[David Crochet]

Bonjour

Le 09/11/2015 19:39, bernard a écrit :

Bonjour,
Je viens de remarquer que les couleurs de la page de téléchargement de
JOSM ont changé.
Les Primary prennent la couleur des secondary
Les Secondary celles des Tertiary
Les Tertiary n'en a plus.
Je n'ai touché à aucun réglage


Normal



Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
dialogue qui nécessite un clic ... inutile.
Pour quelle raison cette modification?


JOSM est un logiciel en constante évolution. S'il y a évolution, c'est 
qu'il y a demande d'évolution.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[Jérôme Seigneuret]

Normal que l'on ne voit pas le message initial de Bernard dans la liste?

Le 9 novembre 2015 20:59, David Crochet  a écrit :

> Bonjour
>
> Le 09/11/2015 19:39, bernard a écrit :
>
>> Bonjour,
>> Je viens de remarquer que les couleurs de la page de téléchargement de
>> JOSM ont changé.
>> Les Primary prennent la couleur des secondary
>> Les Secondary celles des Tertiary
>> Les Tertiary n'en a plus.
>> Je n'ai touché à aucun réglage
>>
>
> Normal
>
>
>> Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
>> dialogue qui nécessite un clic ... inutile.
>> Pour quelle raison cette modification?
>>
>
> JOSM est un logiciel en constante évolution. S'il y a évolution, c'est
> qu'il y a demande d'évolution.
>
> Cordialement
>
> --
> David Crochet
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[Philippe Verdy]

Sur JOSM tu peux choisir tes couleurs dans tes préférences de style.  Sinon
c'est les styles par défaut qui sont téléchargés et remis à jour
régulièrement...
Le 9 nov. 2015 19:40, "bernard"  a écrit :

> Bonjour,
> Je viens de remarquer que les couleurs de la page de téléchargement de
> JOSM ont changé.
> Les Primary prennent la couleur des secondary
> Les Secondary celles des Tertiary
> Les Tertiary n'en a plus.
> Je n'ai touché à aucun réglage
>
> Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
> dialogue qui nécessite un clic ... inutile.
> Pour quelle raison cette modification?
> Bonne soirée et merci pour vos réponses
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[Jérôme Seigneuret]

Le 9 novembre 2015 21:06, Philippe Verdy  a écrit :

> Sur JOSM tu peux choisir tes couleurs dans tes préférences de style.
> Sinon c'est les styles par défaut qui sont téléchargés et remis à jour
> régulièrement...
> Le 9 nov. 2015 19:40, "bernard"  a écrit :
>
>> Bonjour,
>> Je viens de remarquer que les couleurs de la page de téléchargement de
>> JOSM ont changé.
>> Les Primary prennent la couleur des secondary
>> Les Secondary celles des Tertiary
>> Les Tertiary n'en a plus.
>> Je n'ai touché à aucun réglage
>>
> Alors les couleurs ne sont pas liées à JOSM mais au rendu du fond de plan
opemnstreetmap.org (choix de changement présenté sur le blog OSM et dans la
liste d'actu d'OSM France)

Sous JOSM il faudrait géré les épaisseurs pour faire la différence donc
c'est très bien ainsi. On peut remarquer que le rendu JOSM (même si ils
sont proche de l'ancien rendu) n'est pas identique pour simplifier la
lisibilité lors de l'édition et c'est le cas aussi sur iD


>> Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
>> dialogue qui nécessite un clic ... inutile.
>> Pour quelle raison cette modification?
>
> Rien d'inutile. Ça permet de conserver l'identifiant source et de
l'attribuer au tronçon choisi (par défaut celui qui possède le plus de
noeuds)

Pas mal de gens synchronise les données via un identifiant (non visible
mais bien présent dans le format XML ou JSON voir un extrait d'Overpass API

Bonne soirée
Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-latam] talk-latam Digest, Vol 14, Issue 2

[Gonzales, Miriam - (p)]

Hola Rubén

Me gustaría hacer un comentario para evitar crear confusiones:

Red ferroviaria= Railway systems
Metro= Subway

El Metro en México es la red de transporte colectivo (en la mayoría de las 
ocasiones es subterráneo en la Ciudad de México)

En México también aún existe una red ferroviaria pero es usada principalmente 
para transporte de mercancías

No soy experta en el tema pero en sí creo que es importante no confundir los 
dos tipos de transporte al etiquetar

Saludos y gracias



Subject: [talk-latam] Network/Operator tags for railway systems in
Mexico

Las etiquetas network y operator se utilizan para estilos personalizados como 
la adición de logos a la ubicación de las estaciones de metro y distintivas 
secciones diferentes de la red como zonas ferroviarias y divisiones.


Recientemente se ha revisado los datos existentes y no hay muchos usos de estos 
tags en Mexico, Así que este es un buen tiempo para proponer algo que nosotros 
podemos utilizar en el futuro.

En la ciudad de México hasta el momento sólo 2 estaciones tienen el tag de 
network. 1 es `STC Metro` y el otro es simplemente `Metro`.


- "network"="Metro" http://overpass-turbo.eu/s/crc

- "network"="STC Metro" http://overpass-turbo.eu/s/crd



`network=STC Metro` sería una buena etiqueta para proponer la estandarización. 
Pero también podría funcionar `network=Sistema de Transporte Colectivo`, pero  
en el segundo caso esto podría generar  un mal deletreado del nombre y consigo 
una mala escritura de estos.



Como referencias agrego: https://en.wikipedia.org/wiki/Mexico_City_Metro


La red ferroviaria de Mexico es uno de los más largos y característicos y 
nosotros podemos iniciar agregando el tag de `network=STC Metro`  a las 
estaciones y rutas si no hay ninguna objeción de usar el tag.


Saludos,

Ruben.

https://www.openstreetmap.org/user/Rub21
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Subject: Digest Footer

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


--

End of talk-latam Digest, Vol 14, Issue 2
*
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

Re: [talk-au] Highway route number prefixes for QLD and NT

[Ross]

To me your proposed changes appear to be a lot like tagging for the 
renderer:


http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

If the states are not doing alphanumeric then they should not be 
rendered that way.


I'd suggest linking to the routes you are proposing to change and see 
what opinions you get.


I'm sure this has been discussed before and I think the general 
consensus was "only tag with alphanumerics where it is signposted as such".


You may also want to have a look at these:

https://en.wikipedia.org/wiki/List_of_road_routes_in_Queensland

There is a similar wikipedia page for each state.

Cheers
Ross


On 10/11/15 16:19, Leith Bade wrote:

Hi,

I work for Mapbox as their only southern hemisphere contractor based 
in Canberra.


Recently we begun a project to enhance our maps with highway shield 
images.


Most of Australia has been fairly straightforward to develop shield 
selection rules for thanks to the alphanumeric system.


However there are a states where no prefix is used with numeral only 
routes. Particularly Queensland (which has a mix of numeral and 
alphanumeric systems due to ongoing transition), the Northern 
Territory, and West Australia (which have not adopted the alphanumeric 
yet).


In other states prefixes are used to separate National Highways (green 
and gold shields), National Routes (white shields) and State Routes 
(blue shields).


Notably in Melbourne a "S xx" and West Australia a "Sxx" prefix is 
used for blue shield routes. Also in Tasmania "NH1" is used for the 
only non-alphanumeric route.


For national consistency I would like to change all state routes in 
the Northern Territory and Queensland to use a "Sxx" prefix. 
Additionally in West Australia and Northern Territory to change all 
national highways to "NHxx" prefix.


There is no use of a prefix currently anywhere for a national route, 
however changing the few remaining routes in West Australia, Northern 
Territory and Queensland to use a "NRxx" prefix would be useful.


Finally I found state route 24 in Northern Territory is highway=trunk 
when at most it should be highway=primary to match the rest of the 
state. Also in Queensland national route 1 from Cairns heading out 
west is also trunk when at most it should be primary since it does not 
connect to a major city.


I welcome any feedback or suggestions.

Thanks,
Leith Bade
le...@mapbox.com 


___
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

[talk-au] Highway route number prefixes for QLD and NT

[Leith Bade]

Hi,

I work for Mapbox as their only southern hemisphere contractor based in
Canberra.

Recently we begun a project to enhance our maps with highway shield images.

Most of Australia has been fairly straightforward to develop shield
selection rules for thanks to the alphanumeric system.

However there are a states where no prefix is used with numeral only
routes. Particularly Queensland (which has a mix of numeral and
alphanumeric systems due to ongoing transition), the Northern Territory,
and West Australia (which have not adopted the alphanumeric yet).

In other states prefixes are used to separate National Highways (green and
gold shields), National Routes (white shields) and State Routes (blue
shields).

Notably in Melbourne a "S xx" and West Australia a "Sxx" prefix is used for
blue shield routes. Also in Tasmania "NH1" is used for the only
non-alphanumeric route.

For national consistency I would like to change all state routes in the
Northern Territory and Queensland to use a "Sxx" prefix. Additionally in
West Australia and Northern Territory to change all national highways to
"NHxx" prefix.

There is no use of a prefix currently anywhere for a national route,
however changing the few remaining routes in West Australia, Northern
Territory and Queensland to use a "NRxx" prefix would be useful.

Finally I found state route 24 in Northern Territory is highway=trunk when
at most it should be highway=primary to match the rest of the state. Also
in Queensland national route 1 from Cairns heading out west is also trunk
when at most it should be primary since it does not connect to a major city.

I welcome any feedback or suggestions.

Thanks,
Leith Bade
le...@mapbox.com
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[Talk-it] Tipo linea?

[Gianfranco Graizzaro]

>La linea è elettrica, dovrebbe essere 15KV, visto che ci sono solo 3 fili,
ed un solo isolatore fra il filo ed il palo.

 

Linea elettrica trifase da 380 volt con connettori nudi.

Non è da 15 kv. I fili sono molto più distanziati.

 

Jonny

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

[Talk-lt] OpenGIS

[Tomas Straupis]

Sveiki

  2015 spalio mėnesį vykusios OpenGIS konferencijos pristatymus ir
video medžiagą rasite čia:

  Pristatymai: http://www.slideshare.net/opengislt/presentations

  Video: 
https://www.youtube.com/playlist?list=PLlavb6m2j42QxeAQEyOZW_qA_CgMeTgJz

-- 
Tomas

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

Re: [OSM-talk] Undiscussed (?) edits removing lesser-used highway=* tags

[Simon Poole]

As i already pointed out, the problem is not so much fixing obvious
mistakes (typos, clear misclassification) thank you for that, but
wanting conformity to inconclusive results of discussions on a fairly
obscure mailing list.

One of the great strengths of OSM is that you can invent tagging on the
fly and trying to suppress that just so that the data consumers have it
easy, is misguided. In the end the main way our tagging evolves is be
contributors trying to map stuff that doesn't have a popular tagging
scheme associated and not allowing that will reduce new tagging to that
decided by a committee.

Simon

Am 09.11.2015 um 07:39 schrieb GerdP:
> Hi all,
>
> sorry for the late reaction, I was offline for two days visiting a friend
> for his 50th aniversary. 
>
> Andrew Guertin wrote
>> In my opinion, some of these changes are positive and some are negative, 
>> but the negatives outweigh the positives.
> That's bad news for me. I tried to be very careful to improve quality,
> I've asked for feedback in those cases where I was not sure what the
> initial mapper tried to map and AFAIR I got only very few comments
> telling me that I should better revert them. So, please comment 
> those changesets which you think I should revert.
> And yes, during the last days I got a bit lazy asking for review, so I'll 
> add more comments again.
>
>
> Andrew Guertin wrote
>> As a negative example, they seem to have deemed the tag 
>> highway=residential_link bad, and replaced it with either 
>> highway=service or highway=residential. 
>> (https://www.openstreetmap.org/way/18820600/history, 
>> https://www.openstreetmap.org/way/262798921/history).
> I think this should really be discussed in the tagging list.
> I only know a discussion in Germany which came to the 
> conclusion that tags like unclassified_link, residential_link and
> service_link make not much sense:
> http://forum.openstreetmap.org/viewtopic.php?id=26083
> The wiki doesn't mention those _link types as well, and my 
> understanding is that only major roads have a link (if link
> in english means what we call "Abfahrt/ Auffahrt" in Germany,
> I would describe it as a lane that allows to decrease/increase 
> speed.  
>
>
> Andrew Guertin wrote
>> An in-between example: on 
>> https://www.openstreetmap.org/way/38089492/history, 
>> highway=stepping_stones was replaced with highway=path. While this helps 
>> consumers use the data, it loses information that should have been kept 
>> (perhaps with surface=* or something similar).
> I've asked for a comment from the original mapper now. I agree that a
> surface tag
> might be missing, I just recognized this a case of a wrongly mapped ford, so
> I changed 
> the tag to path and added a ford=stepping_stones to the node which connects
> the highway with the waterway.
>
> greetings,
> Gerd (GerdP)
>
>
>
>
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Undiscussed-edits-removing-lesser-used-highway-tags-tp5859298p5859435.html
> Sent from the General Discussion mailing list archive at Nabble.com.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk




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

Re: [Talk-it] Tipo linea?

[michele iw1gfv]

Il 10 Novembre 2015 08:21:53 CET, Gianfranco Graizzaro 
 ha scritto:
>>La linea è elettrica, dovrebbe essere 15KV, visto che ci sono solo 3
>fili,
>ed un solo isolatore fra il filo ed il palo.
>
> 
>
>Linea elettrica trifase da 380 volt con connettori nudi.
>
>Non è da 15 kv. I fili sono molto più distanziati.
>
> 
>
>Jonny
>
>
>
>
>
>___
>Talk-it mailing list
>Talk-it@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-it

ero in dubbio con il 380, perchè spesso hanno isolatori più piccoli, comunque è 
probabilissimo.
-- 
iw1gfv.it
piemontegps.altervista.org

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

[Talk-at] Löschung eines Monsterpolygons?

[Erwin OSM]

Morgen,
da hier im Moment noch mehr mitgelesen wird als im neuen Forum für A ein kurzer 
Hinweis auf eine von mir angestoßene Diskussion:
http://forum.openstreetmap.org/viewtopic.php?id=52639
Hier noch das tolle MP um das es geht:
https://www.openstreetmap.org/relation/4804286
Bin gespannt auf Eure Meinungen.
Grüße
Erwin

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

Re: [OSM-talk-be] more stats: data density in the Belgian regions

[Marc Gemis]

Thanks Joost,

It's always good to see such graphs. I'm interested to learn

* What are we mapping now ?
* What did we map in the past ?
* Who is mapping what  ?
* Who is mapping similar things as me ? (Or am I the only one mapping
feature X ? / can I ask someone also for help with feature X ?)
* Where are we mapping feature X (on town/village level) ?


With "what" I mean e.g. categories of features: streets (highway tags),
landuse/landcover, boundaries, buildings, shops, etc.
However, for some purposes categories might be broken. mapping
amenity=library or amenity=bench are quite different. The same holds for
tourism=hotel and tourism=information,information=board. The library and
hotel are "important" features, bench or an information board not so. I
know "important" is relative, but I hope you understand what I mean.

Of course this is harder when we start thinking about "attributes": turn
lanes, destinations, house numbers, or additional attributes for
amenity=bicycle_parking (such as covered or bicycle_parking=...), etc.

For the last two questions (mapping feature X) the ultimate goal would be
to answer questions such as "Who else is mapping bicycle_parkings ?" With
which attributes. ? Where is feature X not mapped at all ?

Regards

m


On Mon, Nov 9, 2015 at 8:59 AM, joost schouppe 
wrote:

> Hi all,
>
> So, Nicolas' remark after my last post got me interested again in some
> stats about OSM data in Belgium. Is there any difference between Brussels,
> Wallonia and Flanders?
> Of course, I made a little mistake and my laptop will have to redo some
> calculations this night, but here's something that worked.
>
> How did data density evolve in the three parts of the country over the
> last years?
>
> This is a simple count of nodes that were in existence on january first of
> any year. So that includes independent nodes, but also nodes used (and used
> again and again) for building lines and relations.
> To make the regions comparable, I standardized by population. The idea is
> that most stuff that we map is a function of humans, no so much of area.
> (Yes, I know, same population in a larger area would probably imply more
> things to map)
>
> So this graph shows the evolution of nodes per 1000 of population.
> Flanders was clearly highest since 2010. Wallonia started of much quicker
> than Brussels, but can't keep up with Flanders. In Brussels we have a very
> obvious jump in 2014. That's probably the buildings/addresses import.
>
> http://i.imgur.com/RPK38DM.jpg
>
>
> Next thing I want to do is see how many different mappers have built the
> map.
>
> I just stumbled upon the very first nodes and lines in Flanders, and the
> user is still active. The story of these nodes is in his diary, very bottom
> of the page: http://wiki.openstreetmap.org/wiki/User:LA2/Diary_for_Q3_2005
>
>
> --
> Joost @
> Openstreetmap  |
> Twitter  | LinkedIn
>  | Meetup
>  | Reddit
>  | Wordpress
> 
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] more stats: data density in the Belgian regions

[joost schouppe]

Marc,

This is not impossible to achieve. For example, I almost finished an
analysis once to detect which people are/have been mapping biking related
stuff in the past. In my grand scheme of things, I also intend to do
classification of things by group, like you suggested. I'll release some of
these stats about Belgium in the coming days/weeks. Biggest issue: my
processing doesn't do relations, so I do miss some interesting things.

As to the thing you want to do with similar mappers: does it have to be a
history file? I'm not sure, and if it isn't, it's probably easier to do it
on a snapshot. That would make regular updating also easier.
That said, I can release some of my intermediate files as tables or csv,
someone might be able to make some kind of website out of that. But that
would again be with a local scope, as I don't have the capacity to process
global files at once. (I cut up the world in little pieces to run analysis,
but that means you need to finish a processing script before rolling it
out, and I'm not good at finishing things)
Some of the questions you asked have little to do with local context, so it
might be more interesting to see how a thing like taginfo works and build
upon that.

My personal interest is more about "map completeness" for road networks,
landuse, amenities, etc; with a global scope. In the second place mapper
inequality and remote mapping. For things like that, I don't see another
approach than taking world history and cutting it in pieces...


2015-11-10 7:43 GMT+01:00 Marc Gemis :

> Thanks Joost,
>
> It's always good to see such graphs. I'm interested to learn
>
> * What are we mapping now ?
> * What did we map in the past ?
> * Who is mapping what  ?
> * Who is mapping similar things as me ? (Or am I the only one mapping
> feature X ? / can I ask someone also for help with feature X ?)
> * Where are we mapping feature X (on town/village level) ?
>
>
> With "what" I mean e.g. categories of features: streets (highway tags),
> landuse/landcover, boundaries, buildings, shops, etc.
> However, for some purposes categories might be broken. mapping
> amenity=library or amenity=bench are quite different. The same holds for
> tourism=hotel and tourism=information,information=board. The library and
> hotel are "important" features, bench or an information board not so. I
> know "important" is relative, but I hope you understand what I mean.
>
> Of course this is harder when we start thinking about "attributes": turn
> lanes, destinations, house numbers, or additional attributes for
> amenity=bicycle_parking (such as covered or bicycle_parking=...), etc.
>
> For the last two questions (mapping feature X) the ultimate goal would be
> to answer questions such as "Who else is mapping bicycle_parkings ?" With
> which attributes. ? Where is feature X not mapped at all ?
>
> Regards
>
> m
>
>
> On Mon, Nov 9, 2015 at 8:59 AM, joost schouppe 
> wrote:
>
>> Hi all,
>>
>> So, Nicolas' remark after my last post got me interested again in some
>> stats about OSM data in Belgium. Is there any difference between Brussels,
>> Wallonia and Flanders?
>> Of course, I made a little mistake and my laptop will have to redo some
>> calculations this night, but here's something that worked.
>>
>> How did data density evolve in the three parts of the country over the
>> last years?
>>
>> This is a simple count of nodes that were in existence on january first
>> of any year. So that includes independent nodes, but also nodes used (and
>> used again and again) for building lines and relations.
>> To make the regions comparable, I standardized by population. The idea is
>> that most stuff that we map is a function of humans, no so much of area.
>> (Yes, I know, same population in a larger area would probably imply more
>> things to map)
>>
>> So this graph shows the evolution of nodes per 1000 of population.
>> Flanders was clearly highest since 2010. Wallonia started of much quicker
>> than Brussels, but can't keep up with Flanders. In Brussels we have a very
>> obvious jump in 2014. That's probably the buildings/addresses import.
>>
>> http://i.imgur.com/RPK38DM.jpg
>>
>>
>> Next thing I want to do is see how many different mappers have built the
>> map.
>>
>> I just stumbled upon the very first nodes and lines in Flanders, and the
>> user is still active. The story of these nodes is in his diary, very bottom
>> of the page:
>> http://wiki.openstreetmap.org/wiki/User:LA2/Diary_for_Q3_2005
>>
>>
>> --
>> Joost @
>> Openstreetmap  |
>> Twitter  | LinkedIn
>>  | Meetup
>>  | Reddit
>>  | Wordpress
>> 
>>
>> ___
>> Talk-be mailing list
>> 

Re: [OSM-talk-fr] OpenSolarMap...

[Christian Quest]

Il y a plein d'améliorations à faire... n'oubliez pas que ce prototype
tourne depuis même pas 48h !

Effectivement l'icône "?" pourrait plutôt être un moyen de "passer" au
bâtiment suivant plutôt que de répondre... mais c'est vraiment une histoire
de présentation, chose qu'on n'a pas eu le temps d'approfondir (pas de
graphiste/designer dans notre binôme pendant le hackathon).

Si vous voulez proposer des améliorations sur l'interface, vous pouvez le
faire directement, le projet est sur http://github.com/opensolarmap et il
n'y a strictement rien à installer pour la partie "front". C'est juste de
l'HTML5/JS et quelques images qui ont été vite écrits (quick and dirty
comme on dit).
Déjà 2 "pull requests" intégrées hier :)

Côté backend, j'ai modifié un peu la requête de sélection et commencé à
classifier certains bâtiments quand il y a plusieurs réponses identiques
afin de ne plus le sélectionner.
Je dois aussi documenter l'API... et déplacer ça sur un serveur plus stable
(test à venir sur un scaleway).

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

Re: [OSM-talk-fr] OpenSolarMap...

[David Crochet]

Bonjour

Le 10/11/2015 00:25, Jérôme Seigneuret a écrit :

Je ne suis par pour intégrer le contexte environnemental pour le moment
car c'est juste de la détection de type de toit.


De même, sur le principe que l'on a pas implicitement la compétences 
professionnelle pour juger la puissance calorifique reçu par le pan de toit.


Le moyen est de rentrer les paramètre OSM connu des élément autour 
(hauteur des arbres, hauteur des bâtiments, hauteurs des murs.


Cordialement

--
David Crochet

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

Re: [Talk-at] Löschung eines Monsterpolygons?

[Friedrich Volkmann]

On 10.11.2015 07:25, Erwin OSM wrote:
> da hier im Moment noch mehr mitgelesen wird als im neuen Forum für A ein 
> kurzer Hinweis auf eine von mir angestoßene Diskussion:
> http://forum.openstreetmap.org/viewtopic.php?id=52639

Ein neues Forum? Wer hat denn das angelegt, und warum hat er/sie das hier
nicht kundgetan?

Ich finde es keine gute Idee, dass sich die ohnehin spärlichen Diskussionen
mit Österreichbezug jetzt auf ein Forum und eine Mailingliste verteilen.

> Hier noch das tolle MP um das es geht:
> https://www.openstreetmap.org/relation/4804286
> Bin gespannt auf Eure Meinungen.

Wenn ein Wald keinen Namen hat (oder ein anderes Attribut, dass unbedingt
auf die Gesamtfläche gesetzt gehört), ist es mehr oder weniger
Geschmackssache, ob man ihn aufteilt. Es geht dabei nichts kaputt, und
umgekehrt geht auch beim Zusammenlegen nichts kaputt. Die Enscheidung sollte
daher den "Locals" (ich meine die Leute, die in dem Gebiet viel mappen)
überlassen bleiben. Die sind es, die mit den Relationen klarkommen müssen.
Beim Aufteilen sollte man nur schauen, dass die Trennlinien möglichst kurz
und einfach sind. Nicht entlang administrativer Grenzen o.ä., das macht nur
Probleme.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Talk-cz] Import pobočky a bankomaty Česká spořitelna

[Dalibor Jelínek]

Ahoj,

nejsem si jist tou znackou network u bankomatu.

operator je jasne Ceska sporitelna, ale tim network si nejsem tak moc jisty,

jestli je to skutecne jejich vlastni hardware.

 

name importovat nechces?

 

Dalibor

 

From: Marián Kyral [mailto:mky...@email.cz] 
Sent: Monday, November 9, 2015 9:44 PM
To: talk-cz@openstreetmap.org
Subject: Re: [Talk-cz] Import pobočky a bankomaty Česká spořitelna

 

OK,
upravil jsem.

Zároveň jsem přidal další soubor s bankomaty. A co jsem tak koukal, tak tady je 
přesnost zaměření nic moc. Většinou je to uprostřed budovy a těžko můžu určit, 
kde na budově ten bankomat přesně je (pokud má otevírací dobu 24/7 tak asi bude 
na budově ;-) ).

Zkoukněte, hlašte chyby a posílejte návrhy na vylepšení. Aktualizovaný skript 
je na githubu.

Marián

Dne 9.11.2015 v 12:22 Dalibor Jelínek napsal(a):

Cau,

dal bych operator=”Česká spořitelna”, bez toho a.s. protoze tak

uz je to v databazi parkrat pouzito. Viz 
http://taginfo.openstreetmap.cz/keys/operator#values

 

Jinak tu mobilni pobocku bych klidne zmapovat, proc ne?

 

Dalibor

 

 

From: Marián Kyral [mailto:mky...@email.cz] 
Sent: Saturday, November 7, 2015 12:56 AM
To: talk-cz@openstreetmap.org  
Subject: Re: [Talk-cz] Import pobočky a bankomaty Česká spořitelna

 

OK.

tak jsem si trochu hrál. Zatím teda jen s pobočkami.
V příloze je seznam poboček v .csv a osm soubor pro josm.
Ještě to potřebuje poladit - jsou tam i uzavřené pobočky a někde je více bodů 
na sobě - normální banka, pak hypoteční centrum, ERSTE premier centrum...

Taky je tam zajímavá mobilní pobočka. Dle otevíracích hodin je opravdu mobilní. 
Bude nějak vadit, když na mapě bude zaznačená pobočka, která tam je fyzicky jen 
jeden den v týdnu?


Tady je ukázka konverze na text:

===
Coor: 50.220332085400806, 12.190690201661278
Name: Aš
Street: Hlavní 2852/57
City:  Aš
Psč:  35201

Mo:09:00-12:30,13:30-17:00
Tu:09:00-12:30,13:30-15:00
We:09:00-12:30,13:30-17:00
Th:09:00-12:30,13:30-15:00
Fr:09:00-12:30,13:30-16:00
Sa:closed
Su:closed

===
Coor: 49.12111453576768, 14.078102447867357
Name: Bavorov - mobilní pobočka
Street: nám. Míru
City:  Bavorov
Psč:  38773

Mo:closed
Tu:09:00-12:30,13:30-17:00
We:closed
Th:closed
Fr:closed
Sa:closed
Su:closed

===
Coor: 49.294573895691194, 14.469055649686862
Name: Bechyně
Street: nám. T. G. Masaryka 4
City:  Bechyně
Psč:  39165

Mo:08:30-12:30,13:30-17:00
Tu:08:30-12:30,13:30-15:00
We:08:30-12:30,13:30-17:00
Th:08:30-12:30,13:30-15:00
Fr:08:30-12:30,13:30-16:00
Sa:closed
Su:closed


Taky je škoda, že v datech není žádné jednoznačné ID. Bude to dělat problém při 
případné aktualizaci.

Navrhuji následující mapování:

amenity=bank
name=Česká spořitelna, Aš
operator=Česká spořitelna
opening_hour=...
bic=GIBACZPX
source=ceska_sporitelna_gpx

amenity=bank
name=Česká spořitelna, Bavorov
operator=Česká spořitelna
opening_hour=Tu 09:00-12:30,13:30-17:00
bic=GIBACZPX
descrition=Mobilní pobočka
source=ceska_sporitelna_gpx


Kdyby si chtěl někdo hrát, tak může. Skript jsem dal na github.

https://github.com/mkyral/osm/blob/master/import/ceska_sporitelna/prepare_import_files.sh

Marián

Dne 5.11.2015 v 09:42 Dalibor Jelínek napsal(a):

Ahoj,

az budes mit neco pripraveneho, tak to klidne na wiki dam a import 
administrativne zprocesuji.

Uz mam nejake zkusenosti. ;-)

 

Dalibor

 

From: Marián Kyral [mailto:mky...@email.cz] 
Sent: Wednesday, November 4, 2015 7:04 PM
To: talk-cz@openstreetmap.org  
Subject: Re: [Talk-cz] Import pobočky a bankomaty Česká spořitelna

 

Dne 2.11.2015 v 16:50 Petr Schönmann napsal(a):

Ahoj, 
Narazil jsem na zdroj bankomatu a pobocek České spořitelny v gpx. Jako komentář 
mají i otevírací dobu. Někdo na import :)? 
Přidal jsem je k dalším potencionálním zdrojům. 

Hlavní 2852/57, 35201, Aš Provozní doba: Po: 09:00 - 12:30, 13:30 - 17:00, Út: 
09:00 - 12:30, 13:30 - 15:00, St: 09:00 - 12:30, 13:30 - 17:00, Čt: 09:00 - 
12:30, 13:30 - 15:00, Pá: 09:00 - 12:30, 13:30 - 16:00, So: zavřeno, Ne: zavřeno

https://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Bankomaty_a_pobo.C4.8Dky_.C4.8Cesk.C3.A1_spo.C5.99itelna

 


Ahoj,
Koukal jsem na to, asi by to nebylo až tak složité. Udělat nějaký python script 
který to nacpe do databáze, tam to překonvertovat a vygenerovat soubor pro 
josm. Případně to ještě zkusit spojit s existujícími daty. A začištění pak 
třeba pomocí HOT task manageru (když už ho máme). Podobný postup by pak šel 
použít i u dalších datových sad. V létě jsem třeba komunikoval s paní od Čepra. 
Ptal jsem se na licenci těch čerpacích stanic EuroOil a získal jsem od ní 
svolení k importu do OSM. Jenže pak se toho nakupilo nějak moc a musel jsem to 
odložit.

Snad se k tomu během zimy dostanu.

Hlásí se nějaký dobrovolník na vyřízení nezbytné 

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

[Julien Noblet]

Bonjour,
Merci :)

J'avais complètement zappé le landuse=residential :/

Librement.
Julien_N

Le lun. 9 nov. 2015 à 19:47, Jérôme Seigneuret  a
écrit :

> Bonjour,
> Le nom de la résidence se met par usage sur le landuse. Il faut découper
> le landuse existant pour éviter les superpositions de landuse.
>
> Le nom du bâtiment sur building
>
> Jérôme
>
> Le 9 novembre 2015 19:39, Julien Noblet  a écrit
> :
>
>> Bonjour,
>> Je viens vers vous pour savoir comment taguer une résidence ou une cité
>> de plusieurs bâtiments.
>> J'avais pensé à une relation de "type"="site"
>> name=
>> Avec un chemin avec un rôle perimeter, et les bâtiments avec un rôle
>> building.
>> Chaque bâtiment peut avoir un nom (ou plutôt une ref) name/ref = Bâtiment
>> A/B/C/D...
>>
>> Quels tags devraient être ajoutés la relation?
>>
>> Est-ce que j'ai tout faux et je devrais utiliser sur les bâtiment un
>> addr:place ou addr:X=?
>>
>> Merci par avance.
>> Librement.
>>
>> Julien_N
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Preklad Crossover track?

[Jethro]

Ahoj,
jednoduchá a dvojitá kolejová spojka jsou standardně používané
železničářské termíny.
Jethro

2015-11-09 10:16 GMT+01:00 honny :
> Zdar,
>
> jj, termínu (jednoduchá/dvojitá) kolejová spojka bych se nebál.
>
> http://fast10.vsb.cz/mahdalova/doprstav/pred11fs.pdf  (s. 14)
>
>
> h.
>
>
>
> Dne 9. listopadu 2015 10:06 Jozef Riha  napsal(a):
>> ahoj, zelezniciar nie som, ale slovnik.sms.cz dava na crossover tieto hesla:
>>
>> křížová kolejová spojka, kolejová spojka a dalej potom:
>>
>> single crossover - jednoduchá kolejová spojka
>>
>> 2015-11-09 9:55 GMT+01:00 Dalibor Jelínek :
>>>
>>> Ahoj,
>>>
>>> je tu nejaky zeleznicar?
>>>
>>> Prekladam stranku
>>> http://wiki.openstreetmap.org/wiki/Cs:Key:service#Crossover_Track
>>>
>>> a nevim si rady s terminem Crossover Track.
>>>
>>> Nevite nekdo, jak se to preklada do cestiny?
>>>
>>>
>>>
>>> Dekuji,
>>>
>>> Dalibor
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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
>>
>
> ___
> 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: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Philippe Verdy]

Ce n'était qu'une proposition.

Si ça te plait et tu veux l"utiliser, documente-là sur le wiki, au moins
pour dire que century=11 signifie 11e siècle (1001-1100) et non les années
1100-1199, et soulever le problème.

Attends-toi ensuite à des contre-propositions sur le wiki et des
discussions (certains voudront quand même utiliser start_date=* mais avec
une syntaxe permettant de spécifier un intervalle de dates pour les dates
estimées, par exemple "start_date=1001..1100" qui n'entre pas en conflit
avec la notation ISO 8601 des dates).

Pouvoir indiquer des dates estimées avec une fourchette suffixante est plus
objectif qu'une classification difficile (et subjective) des époques et
civilisations, avec des tas de valeurs possibles et une difficulté ensuite
à les traiter.. Mais la simple notation du siècle est malgré tout un usage
très répandu partout dans le monde.

Note: certaines parties d'un batiment ont plusieurs époques et parfois les
époques se superposent au même endroit (reste d'un mur ancien sur lequel
est construit ou reconstruit un élément plus récent. et cela est presque
toujours le cas des batiments historiques les plus anciens (abbayes,
cathédrales, églises, chateaux, fortifications, aqueducs/viaducs...). Pour
les batiments les plus récents, on ne les mentionne pas par un siècle mais
par une année de construction plus précise (mais il n'est pas impossible
d'avoir une construction très récente et datée précisément sur une
fondation plus ancienne, incluant même la préservation de certains éléments
historiques comme une façade, un pan de mur, une tour...)

Le 9 novembre 2015 11:28, Jérôme Seigneuret  a
écrit :

> Merci Philippe. Je vais mettre historic:century=11
>
>
> Le 9 novembre 2015 11:19, Philippe Verdy  a écrit :
>
>> tu peux proposer "historic:century=11" si la classification par époque ou
>> civilisation est difficile (d'ailleurs elle varie selon les pays ou
>> cultures, ce qui est documenté est difficile à standardiser et faire
>> accepter partout).
>> le "start_date=*" est plutôt réservé à noter des dates précises (avec un
>> format compatible ISO 8601 contenant au minimum une année complète), mais
>> le XIe siècle n'est pas assez précis on ne peut pas non plus mettre
>> "start_date=1001-1100" (format incompatible posant problème),
>> start_date=1001 (oui, le XIe siècle commence l'année suivant l'an mil) ou
>> start_date=1050 (milieu du siècle) serait au contraire trop précis (rien
>> n'indique que c'est en fait une estimation à plus ou mois 50 ans près).
>>
>> Le 9 novembre 2015 11:07, Jérôme Seigneuret  a
>> écrit :
>>
>>> Bonjour, en faisant un fix sur le nom d'une église je me retrouve à
>>> avoir:
>>> Église ST Barthélémy XIième siècle que je corrige en Église
>>> Saint-Barthélémy-de-Baillarguet
>>>
>>> Mon problème est d'ajouter l'information lié au XI ème siècle
>>> > période du moyen age central + précision sur le siècle
>>>
>>> Ducoup je regarde du coté des tags
>>> http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilization
>>> historic:period 
>>> =
>>> start_date =
>>>
>>> Je me rend compte que rien n'est précisé sur les siècles tel que l'on a
>>> l'habitude de l'utilisé d'une part et que les grandes périodes de notre
>>> civilisation ne sont pas détaillé:
>>> préhistoire et protohistoire c'est OK
>>>
>>>- *historic:civilization*=prehistoric
>>>- *historic:civilization*=protohistoric
>>>
>>>
>>> Reste les périodes après JC et les périodes spécifique à des régions
>>>
>>> moyen-age :vie ‑xve
>>>
>>> haut Moyen Âge = : vie ‑ xe siècle
>>> Moyen Âge central : xie ‑ xiiie siècle
>>> Moyen Âge tardif 
>>>  : xive ‑ xve siècle
>>>
>>>
>>> époque moderne :
>>>
>>> Époque moderne antérieure :1492 – 1792
>>>
>>> époque contemporaine :
>>>
>>> Époque moderne I : 1792 – 1920
>>> Époque moderne II : 1920 à nos jours
>>>
>>>
>>> Bonne journée
>>> Jérôme
>>>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] La mappa di OSM ha un nuovo schema colori

[Andrea Guglielmo]

Il 07 novembre 2015 23:39:54 CET, Marco Ciampa  ha scritto:
>On Sat, Nov 07, 2015 at 08:36:07AM -0700, Aury88 wrote:
>> dieterdreist wrote
>> > Ammetto, ho un po' perso il filo, di cosa discutiamo qui? O
>discutiamo per
>> > discutere?
>>
>> temo la seconda... a parte gli iniziali messaggi sull'avviso del
>> cambiamento dei colori della mappa da li in poi è stato un "io
>vorrei" e un 
>> "io non vorrei" e quindi una discussione così "da bar" senza alcuna
>finalità
>> pratica o possibilità di vederla realizzata finché la si discute qui
>
>Non sono d'accordo con te, ma è la prima volta ;-). Ho seguito con
>passione il thread e devo dire che sono stato praticamente sempre
>d'accordo con te Aury88. Il discorso riguardava l'accrescimento delle
>funzionalità web di osm che anche secondo me sono molto importanti per
>la
>visibilità e in ultima analisi per tutto il progetto osm. Si discute
>per
>confrontarsi e vedere se ci si trova d'accordo prima di andare avanti e
>proporre la cosa direttamente. Forse qualcuno che parla con te si trova
>nella condizione di poter aggiungere, direttamente o indirettamente,
>una
>di queste funzionalità. È sempre utile confrontarsi. Almeno io l'ho
>trovata una discussione molto interessante.
>
>Grazie,
>
>--
>
>
>Marco Ciampa
>

Sono d'accordo completamente con Marco, nessuno ci impedisce di proporre a chi 
di dovere le migliorie e magari anche chi può contribuire al codice. 
Purtroppo la mappa di OSM più volte l'ho sentita nominare come "rudimentale" 
per il suo aspetto ed è la prima cosa su cui intervenire, la seconda i servizi, 
perché chi arriva su osm non sa, o non vuole approfondire cosa sia OSM e di una 
pagina che gli mostra solo una mappa, poco se ne fanno, vogliono poterla 
"utilizzare". Maggiore popolarità vuol dire che se OSM chiederà di contribuire 
con moneta sonante, ci sarà più possibilità di ricevere maggior soldi, tra le 
altre cose... 
Non credo che sia difficile reperire sviluppatori per implementare i servizi, 
basta provare a chiedere a chi già sviluppa software libero utilizzando il DB 
di OSM. In quanti sviluppatori sanno che OSM non può offrire servizi in più per 
mancanza di volontari che mettano mano al codice? Poi di progetti liberi ce ne 
sono, bisognerebbe integrarli in osm. Per esperienza personale, posso affermare 
che molte volte è la mancanza di conoscenza che frena un progetto. OSM va fatto 
conoscere! Troppe persone non sanno neanche che esiste!

Andrea Lattmann

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

Re: [Talk-cz] Prapodivná trasa

[Marián Kyral]

-- Původní zpráva --
Od: jzvc 
Komu: talk-cz@openstreetmap.org
Datum: 9. 11. 2015 11:49:24
Předmět: Re: [Talk-cz] Prapodivná trasa

"Dne 7.11.2015 v 22:38 Marián Kyral napsal(a):
> Dne 7.11.2015 v 21:57 Pavel Machek napsal(a):
>> Ahoj!
>>
>>> Zřejmě nepočítá se Shengenem. Jak se vůbec tagují hraniční přechody? A
>>> tagují se vůbec?
>> No ono zas... ne pro vsechno je Shengen relevantni. Kdyz budu
>> potrebovat prevyst kravu, tak me pri ceste pres 2 staty nejspis bude
>> cekat vyrazne vic papirovani. (Nebudu ji muset nahodou po prekroceni
>> hranice dat na par dni do karanteny?) Takze ho malicko chapu... i kdyz
>> pro bezne pouziti to asi neni chytre.
>>
>> Pavel
>
> Právě proto jsem se ptal, jestli se hraniční přechod nějak značí. Je
> samozřejmé, že pro různé typy dopravy osob a zboží budou jiné podmínky.
> Na dálnici taky platí osobní auta jinak než nákladní.
> Jde právě o to, nějak routování napovědět. Ale to je asi lepší řešit
> jinde, tohle by bylo dobré nastavit celosvětově.
>
> Marián

Cus,

on fyzicky na danym miste zadnej prechod vetsinou neni. Pokud samo 
pomineme hromady nepouzivanych budov, ktere se za jeste vetsi hromady 
penez vybudovaly, aby se pak zavrely.

BTW: Routovani prece snadno muze zjistit, ze prekracujes statni hranici. 
Prusecik dvou cest zas neni tak slozity spocitat.

A ad krava, pokud ji deklarujes jako sve domaci zvire ... ;D tak ti 
staci ockovak + "pas".
"



Ne,

mně šlo o to, jak routeru sdělit, že na dané hranici není, za normálních 
okolností, pasová kontrola a tudíž průjezd přes hranici nepředstavuje žádné 
zdržení.




Ten problém je o tom, že router preferuje průjezd přes co nejméně hranic I 
za cenu docela velké zajížďky. Zřejmě právě na přechodu státních hranic 
počítá s časem navíc.




Marián




"
>
> ___
> 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;___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] Problème de nommage de rue

[Donat ROBAUX]

+1 avec Jérome. Pour le terrain je mettrai le type de voie que les gens
utilisent le plus.

Le mieux étant d'aller voir la délibération du conseil municipal. Sinon la
règle étant de mettre le nom en clair sans abréviation.

Donat



> -- Message transféré --
> From: "Jérôme Seigneuret" 
> To: "Discussions sur OSM en français" 
> Cc:
> Date: Mon, 9 Nov 2015 11:24:38 +0100
> Subject: Re: [OSM-talk-fr] Problème de nommage de rue
> Bonjour,
> Le choix se fait avec le terrain.
> Je mets le code FANTOIR de la rue la mieux nommée et l'autre je la déclare
> comme "Voie doublon et type de voie différent"
>
> Jérôme
>
> Le 9 novembre 2015 11:16, Ludovic Hirlimann  a
> écrit :
>
>> je n'ai pas de problème avec Jean Jacques LEFRANC dans mon exemple. J'ai
>> plus des problèmes avec rue/avenue et avec la partie manquante "de
>> pompignan" , comment choisir entre rue et ave ? (j pense prendre le de
>> pompugnan car présent dans le cadastre.
>>
>> Ludo
>>
>>
>> 2015-11-09 11:10 GMT+01:00 Philippe Verdy :
>>
>>> Les panneaux peuvent parfois utiliser des abréviations (comme ici les
>>> prénoms), la poste aussi (pas toujours les mêmes, la Poste imposant des
>>> noms plus courts pour les adresses normalisées sur les enveloppes peut
>>> avoir utilisé ses propres abréviations). Les planches cadastrales ont aussi
>>> leurs abréviations.
>>>
>>> Le FANTOIR enfin abrège aussi à cause du format du fichier (il y a déjà
>>> les codes pout les types de voie, il manque tous les accents et souvent des
>>> apostrophes ou traits d'union, souvent aucun point abréviatif, et aucune
>>> distinction des casses de lettres.
>>>
>>> Dans OSM on évite ces abréviations et autant que possible on restaure
>>> les noms entiers, les accents, la casse, les apostrophes et traits d'union
>>> corrects (le rapprochement avec FANTOIR reste encore facile avec la
>>> ref:FR:FANTOIR=* malgré ce nom remis en forme, même si le format FANTOIR a
>>> été conçu du temps des vieux logiciels écrits en COBOL sur des systèmes qui
>>> ne savait échanger correctement entre eux que de l'ASCII). C'est au
>>> logiciel de rendu de choisir ensuite la façon d'abréger (si nécessaire) ou
>>> un style d'affichage tout en capitales.
>>>
>>> Quand aux "sauts de lignes" présents sur les panneaux ou dans le
>>> cadastre, ne pas en tenir compte et les traiter comme des blancs.
>>>
>>> Le 9 novembre 2015 10:58, Ludovic Hirlimann  a
>>> écrit :
>>>
 Coucou,

 j'ai commencé a participer au projet BANO, il y a trois semaine. J'ai
 plus ou moins fini ma ville et je me suis donc attelé au village voisin.
 J'ai un soucis avec la commune de Pompignan
 http://cadastre.openstreetmap.fr/fantoir/#insee=82142=0.

 La rue Jean Jacques lefranc :

 https://www.openstreetmap.org/edit#map=18/43.81764/1.31263


 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.81742/1.31282

 en bas de la voie (et à gauche sur la carte) il y a un panneau avec la
 mention :
 Rue
 J. Jacques
 LEFRANC

 Juste au niveau du coude (là ou est le n°19 sur la vue BANO) il y a un
 autre panneau avec la mention

 AVENUE
 J. J. LEFRANC
 DE POMPIGNAN

 Le cadastre réference RUE JJ LEFRANC DE POMPIGNAN

 La commune en question n'est vraiment pas clair organisé sur ses
 panneaux de voiries.

 Ma question est donc, commen dois-je nommer le rue ? que faire dans
 FANTOIR ?


 Ludo
 --
 http://sietch-tabr.tumblr.com/


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

Re: [OSM-talk-fr] Problème de nommage de rue

[Philippe Verdy]

Si sur le terrain on trouve les deux, I doit y avoir un usage même si ce
n'est pas le nom officiel.  Pour faciliter les recherches et le géocodage,
un alt_name=* sera alors utile en plus du nom officiel dans name=*
Le 9 nov. 2015 12:06, "Donat ROBAUX"  a écrit :

> +1 avec Jérome. Pour le terrain je mettrai le type de voie que les gens
> utilisent le plus.
>
> Le mieux étant d'aller voir la délibération du conseil municipal. Sinon la
> règle étant de mettre le nom en clair sans abréviation.
>
> Donat
>
>
>
>> -- Message transféré --
>> From: "Jérôme Seigneuret" 
>> To: "Discussions sur OSM en français" 
>> Cc:
>> Date: Mon, 9 Nov 2015 11:24:38 +0100
>> Subject: Re: [OSM-talk-fr] Problème de nommage de rue
>> Bonjour,
>> Le choix se fait avec le terrain.
>> Je mets le code FANTOIR de la rue la mieux nommée et l'autre je la
>> déclare comme "Voie doublon et type de voie différent"
>>
>> Jérôme
>>
>> Le 9 novembre 2015 11:16, Ludovic Hirlimann  a
>> écrit :
>>
>>> je n'ai pas de problème avec Jean Jacques LEFRANC dans mon exemple. J'ai
>>> plus des problèmes avec rue/avenue et avec la partie manquante "de
>>> pompignan" , comment choisir entre rue et ave ? (j pense prendre le de
>>> pompugnan car présent dans le cadastre.
>>>
>>> Ludo
>>>
>>>
>>> 2015-11-09 11:10 GMT+01:00 Philippe Verdy :
>>>
 Les panneaux peuvent parfois utiliser des abréviations (comme ici les
 prénoms), la poste aussi (pas toujours les mêmes, la Poste imposant des
 noms plus courts pour les adresses normalisées sur les enveloppes peut
 avoir utilisé ses propres abréviations). Les planches cadastrales ont aussi
 leurs abréviations.

 Le FANTOIR enfin abrège aussi à cause du format du fichier (il y a déjà
 les codes pout les types de voie, il manque tous les accents et souvent des
 apostrophes ou traits d'union, souvent aucun point abréviatif, et aucune
 distinction des casses de lettres.

 Dans OSM on évite ces abréviations et autant que possible on restaure
 les noms entiers, les accents, la casse, les apostrophes et traits d'union
 corrects (le rapprochement avec FANTOIR reste encore facile avec la
 ref:FR:FANTOIR=* malgré ce nom remis en forme, même si le format FANTOIR a
 été conçu du temps des vieux logiciels écrits en COBOL sur des systèmes qui
 ne savait échanger correctement entre eux que de l'ASCII). C'est au
 logiciel de rendu de choisir ensuite la façon d'abréger (si nécessaire) ou
 un style d'affichage tout en capitales.

 Quand aux "sauts de lignes" présents sur les panneaux ou dans le
 cadastre, ne pas en tenir compte et les traiter comme des blancs.

 Le 9 novembre 2015 10:58, Ludovic Hirlimann  a
 écrit :

> Coucou,
>
> j'ai commencé a participer au projet BANO, il y a trois semaine. J'ai
> plus ou moins fini ma ville et je me suis donc attelé au village voisin.
> J'ai un soucis avec la commune de Pompignan
> http://cadastre.openstreetmap.fr/fantoir/#insee=82142=0.
>
> La rue Jean Jacques lefranc :
>
> https://www.openstreetmap.org/edit#map=18/43.81764/1.31263
>
>
> http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.81742/1.31282
>
> en bas de la voie (et à gauche sur la carte) il y a un panneau avec la
> mention :
> Rue
> J. Jacques
> LEFRANC
>
> Juste au niveau du coude (là ou est le n°19 sur la vue BANO) il y a un
> autre panneau avec la mention
>
> AVENUE
> J. J. LEFRANC
> DE POMPIGNAN
>
> Le cadastre réference RUE JJ LEFRANC DE POMPIGNAN
>
> La commune en question n'est vraiment pas clair organisé sur ses
> panneaux de voiries.
>
> Ma question est donc, commen dois-je nommer le rue ? que faire dans
> FANTOIR ?
>
>
> Ludo
> --
> http://sietch-tabr.tumblr.com/
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Rouen - Pont Mathilde - j'ai un doute sur 3 voies

[david . crochet]

Bonjour

Vous en pensez quoi de ces trois voies :

https://www.openstreetmap.org/way/188324016 
https://www.openstreetmap.org/way/188324013
https://www.openstreetmap.org/way/44785324

ils se suivent et des étiquettes ne sont pas "homogènes"

Cordialement

-- 
David Crochet

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

Re: [Talk-it] Mappa osmand italia

[Marco_T]

Max1234Ita wrote
> Mah, alla fine la versione Free limita il *numero* di download totali.
> Che siano da un server ufficiale o da uno custom, poco importa, credo:
> basterebbe incrementare ad hoc il conteggio globale: al termine dei
> tentativi concessi l'utente si troverebbe comunque con la schermata che
> invita a passare alla versione a pagamento.
> 
> Max

Segnalo, in ritardo, che su Android invece/oltre a Gplay potete usare il
gestore di applicazioni F-Droid che trovate qui:
https://f-droid.org/
F-Droid contiene solo applicazioni FOSS (tutte verificate e ricompilate da
loro) e qui potete scaricare la versione OsmAnd Full senza limitazioni nel
numero di download.
Nella sezione "Navigazione" di F-Droid ci sono, inoltre, molte altre
applicazioni che usano mappe OSM.
Saluti.

-- 
Marco_T



--
View this message in context: 
http://gis.19327.n5.nabble.com/Mappa-osmand-italia-tp5855526p5859464.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-cz] Import pobočky a bankomaty Česká spořitelna

[Dalibor Jelínek]

Cau,

dal bych operator=”Česká spořitelna”, bez toho a.s. protoze tak

uz je to v databazi parkrat pouzito. Viz 
http://taginfo.openstreetmap.cz/keys/operator#values

 

Jinak tu mobilni pobocku bych klidne zmapovat, proc ne?

 

Dalibor

 

 

From: Marián Kyral [mailto:mky...@email.cz] 
Sent: Saturday, November 7, 2015 12:56 AM
To: talk-cz@openstreetmap.org
Subject: Re: [Talk-cz] Import pobočky a bankomaty Česká spořitelna

 

OK.

tak jsem si trochu hrál. Zatím teda jen s pobočkami.
V příloze je seznam poboček v .csv a osm soubor pro josm.
Ještě to potřebuje poladit - jsou tam i uzavřené pobočky a někde je více bodů 
na sobě - normální banka, pak hypoteční centrum, ERSTE premier centrum...

Taky je tam zajímavá mobilní pobočka. Dle otevíracích hodin je opravdu mobilní. 
Bude nějak vadit, když na mapě bude zaznačená pobočka, která tam je fyzicky jen 
jeden den v týdnu?


Tady je ukázka konverze na text:

===
Coor: 50.220332085400806, 12.190690201661278
Name: Aš
Street: Hlavní 2852/57
City:  Aš
Psč:  35201

Mo:09:00-12:30,13:30-17:00
Tu:09:00-12:30,13:30-15:00
We:09:00-12:30,13:30-17:00
Th:09:00-12:30,13:30-15:00
Fr:09:00-12:30,13:30-16:00
Sa:closed
Su:closed

===
Coor: 49.12111453576768, 14.078102447867357
Name: Bavorov - mobilní pobočka
Street: nám. Míru
City:  Bavorov
Psč:  38773

Mo:closed
Tu:09:00-12:30,13:30-17:00
We:closed
Th:closed
Fr:closed
Sa:closed
Su:closed

===
Coor: 49.294573895691194, 14.469055649686862
Name: Bechyně
Street: nám. T. G. Masaryka 4
City:  Bechyně
Psč:  39165

Mo:08:30-12:30,13:30-17:00
Tu:08:30-12:30,13:30-15:00
We:08:30-12:30,13:30-17:00
Th:08:30-12:30,13:30-15:00
Fr:08:30-12:30,13:30-16:00
Sa:closed
Su:closed


Taky je škoda, že v datech není žádné jednoznačné ID. Bude to dělat problém při 
případné aktualizaci.

Navrhuji následující mapování:

amenity=bank
name=Česká spořitelna, Aš
operator=Česká spořitelna
opening_hour=...
bic=GIBACZPX
source=ceska_sporitelna_gpx

amenity=bank
name=Česká spořitelna, Bavorov
operator=Česká spořitelna
opening_hour=Tu 09:00-12:30,13:30-17:00
bic=GIBACZPX
descrition=Mobilní pobočka
source=ceska_sporitelna_gpx


Kdyby si chtěl někdo hrát, tak může. Skript jsem dal na github.

https://github.com/mkyral/osm/blob/master/import/ceska_sporitelna/prepare_import_files.sh

Marián

Dne 5.11.2015 v 09:42 Dalibor Jelínek napsal(a):

Ahoj,

az budes mit neco pripraveneho, tak to klidne na wiki dam a import 
administrativne zprocesuji.

Uz mam nejake zkusenosti. ;-)

 

Dalibor

 

From: Marián Kyral [mailto:mky...@email.cz] 
Sent: Wednesday, November 4, 2015 7:04 PM
To: talk-cz@openstreetmap.org  
Subject: Re: [Talk-cz] Import pobočky a bankomaty Česká spořitelna

 

Dne 2.11.2015 v 16:50 Petr Schönmann napsal(a):

Ahoj, 
Narazil jsem na zdroj bankomatu a pobocek České spořitelny v gpx. Jako komentář 
mají i otevírací dobu. Někdo na import :)? 
Přidal jsem je k dalším potencionálním zdrojům. 

Hlavní 2852/57, 35201, Aš Provozní doba: Po: 09:00 - 12:30, 13:30 - 17:00, Út: 
09:00 - 12:30, 13:30 - 15:00, St: 09:00 - 12:30, 13:30 - 17:00, Čt: 09:00 - 
12:30, 13:30 - 15:00, Pá: 09:00 - 12:30, 13:30 - 16:00, So: zavřeno, Ne: zavřeno

https://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#Bankomaty_a_pobo.C4.8Dky_.C4.8Cesk.C3.A1_spo.C5.99itelna

 


Ahoj,
Koukal jsem na to, asi by to nebylo až tak složité. Udělat nějaký python script 
který to nacpe do databáze, tam to překonvertovat a vygenerovat soubor pro 
josm. Případně to ještě zkusit spojit s existujícími daty. A začištění pak 
třeba pomocí HOT task manageru (když už ho máme). Podobný postup by pak šel 
použít i u dalších datových sad. V létě jsem třeba komunikoval s paní od Čepra. 
Ptal jsem se na licenci těch čerpacích stanic EuroOil a získal jsem od ní 
svolení k importu do OSM. Jenže pak se toho nakupilo nějak moc a musel jsem to 
odložit.

Snad se k tomu během zimy dostanu.

Hlásí se nějaký dobrovolník na vyřízení nezbytné administrativy? Příprava CZ a 
EN stránky importu na wiki a následná komunikace s @imports? Skripty budou to 
nejmenší ;-)

Marián










___
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

 

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

Re: [OSM-talk-fr] tag source:maxspeed=:zone:30

[Axelos]

Coucou,


lenny.libre wrote
> Quant à zone:maxspeed=FR:zone:30 il y a des infos en plus de la vitesse 
> : les piétons peuvent traverser, il n'y a pas de passage protégé et  
> toutes  les  chaussées  sont  à  double  sens pour  les cyclistes ...

Attention de ne pas confondre les zones de rencontre et les zones 30 :

Sur les zones 30, les piétons ont pour obligation de traverser sur les
passages prévus à cet effet (sauf si ceux-ci se trouvent à plus de 50
mètres).
C'est sur les zones de rencontre que les passages cloutés ne sont pas
obligatoires.

Concernant les cyclistes à contre sens, il y a eu début juillet cette année
des modifications du code de la route, dont le double sens cyclable par
défaut sur les routes limitées à 30 et non plus en uniquement en zone 30. Ce
sera effectif des le 1 janvier 2016, soit environ 6 mois pour que les
communes adaptent leurs signalisations. On pourra compter à cette date sur
les associations qui défendent la cyclabilité pour vérifier si oui ou non
les communes auront leurs précieux sésames pour chacune des rues : "sauf
décision contraire de l'autorité de police".

Sources :
http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06074228=LEGIARTI30839280
http://www.legifrance.gouv.fr/affichTexteArticle.do;jsessionid=FF4FC290C34361519E9E84AD8F1E4B51.tpdila13v_1?idArticle=JORFARTI30837283=JORFTEXT30837215

Cordialement.



--
View this message in context: 
http://gis.19327.n5.nabble.com/tag-source-maxspeed-country-code-zone-30-tp5859417p5859466.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [Talk-it] La mappa di OSM ha un nuovo schema colori

[Paolo Monegato]

Il 07/11/2015 12:55, Aury88 ha scritto:
gmap si fa pagare ma non da sempre. naturalmente prima di adottarla 
devono controllare cosa offre mi sembrava talmente ovvio che non 
valesse neanche la pena specificarlo...una mappa bianca è utile meno 
della carta igienica...tu parlavi del fatto che la adottassero perchè 
la conoscevano, io parlavo del fatto che non è così...l'adottano 
perchè cercano qualcosa, trovano qualcosa, la valutano positivamente e 
la usano..


Per me quel "la trovano e la valutano positivamente" equivale a dire che 
la conoscevano prima di adottarla.



chiedi anche quanti l'hanno adottata perchè la utilizzavano regolarmente
online...così per curiosità tanto per avere anche io qualche dato in più
sull'argomento ;-)


A quanto pare la mia impressione era non del tutto giusta... ma magari i 
risultati del mio piccolo sondaggio sono dovuti al caso (magari apro una 
discussione per avere un campione più vasto). Comunque, solo 1 di loro 
aveva conosciuto OSM perché gliene aveva parlato qualcun altro e/o ne 
aveva sentito parlare ad un incontro presso il suo LUG (quindi con me 
eravamo in 2). Il resto della compagnia (gli altri 5) aveva trovato OSM 
per caso: c'era chi cercava una mappa dove si potesse mettere la sua 
via, che essendo nuova non era presente nelle altre mappe e dunque non 
riusciva a ricevere a casa i corrieri espresso; poi c'era chi aveva 
bisogno di una mappa libera per programmare un escursione ciclistica; 
chi semplicemente l'ha trovata per caso e così via.



Perché, date la birra gratis durante i vostri eventi?

  qui da me non ci sono eventi purtroppo, ma ho sentito che nei paesi
anglosassoni e forse anche nel resto del nord europa spesso gli eventi sono
a base di birra con "assaggio" gratuito o scontato per la
comitiva...interessato anche tu? :-)


Purtroppo leggo che Martin ci ha deluso entrambi... Comunque può essere 
un'idea, sicuramente tra i mapper c'è qualche homebrewer e si potrebbe 
provare a vedere se funziona come attrattiva...



ok, capito. abbiamo due concetti diversi del termine conoscenza...per me è
una cosa di cui tieni a mente che esiste o come alternativa...temo che
l'assenza dei servizi in genere oltre a deludere l'utente e a fargli
cambiare sito di fatto rimuova le informazioni fino a li aquisite del
sito...tu in quanti siti sei andato in tutta la tua vita? li conosci
tutti?secondo se prendiamo per vero il mio ragionamento sulla ricerca del
servizio tramite motore semplicemente l'utente non verrà a sapere di noi se
sceglie le mappe "concorrenti" oppure potrebbe non accorgersi di noi se usa
uno dei servizi che si appoggiano su osm.


C'è da dire però che non tutti i siti ti forniscono un servizio così 
particolare e diverso dal resto che c'è in giro. Credo sia più facile 
ricordarsi di OSM che di un blog qualsiasi.



No, è una questione di definizione. Una mappa è per definizione una
riproduzione bidimensionale, approssimata, ridotta e simbolica.

ci sono anche le mappe 3d...ci sono le mappe come la nostra che non
sono solo una rappresentazione simbolica, ma anche un insieme di
collegamenti e dati "logici". se fosse solo il rispetto della definizione di
mappa da te data a determinare l'utilizzo non si spiegherebbe perchè per
certi ambiti si utilizzano certi tipi di mappe e per altri altri tipi di
mappe... ne basterebbe una...il fatto è che in base allo scopo per cui lo
utilizzi ti servono alcuni elementi ed altri no...ecco che magari per un
utilizzo a fortissimo zoom ti può servire vedere quello che realmente c'è
oppure vederne solo una rappresentazione bidimensionale approssimata e
ridotta..


??
Mi pare chiaro che lo scopo della mappa ne determini molti aspetti: 
dalla scala agli oggetti rappresentati simbolicamente. Tu invece 
sostenevi che la mancanza di molti dettagli e della foto aerea sullo 
sfondo è a causa della limitazione tecnica del mezzo e della mancanza 
della possibilità di fare lo zoom.
Certamente le mappe online con la possibilità di zoommare hanno un po' 
cambiato le cose. Ma restano tuttora delle rappresentazioni simboliche: 
si vedano i simboli che rappresentano i vari POI o anche le strade che 
sono rappresentate con una linea. Ed anche gli altri aspetti restano 
costanti:
- è bidimensionale (non è mica un plastico... il 3d lo fai con qualche 
trucchetto grafico),
- è approssimata (perché un certo grado d'errore c'è sempre... anche se 
si escludesse l'errore di precisione nel rilevamento rimane comunque il 
fatto che si sta portando un geoide su un piano, dunque in qualche modo 
viene distorto il tutto)
- ed è ridotta, perché anche se ora si può zoommare a piacere è comunque 
in scala (qui volendo potrebbe partire tutto il discorso sulla mappa 1 a 
1, ma direi che non è il caso di scomodare Borges ed Eco)



L'ortofoto non è una mappa.

  ciò non significa che la puoi utilizzare per orientarti o per attività per
cui anche una mappa è utilizzabile...ciò non significa che magari qualcuno
la torvi più comoda per certe attività per 

[OSM-talk-fr] Avis aux franciliens

[Romain MEHUT]

Bonjour,

Ayant dû emprunter tout récemment le boulevard périphérique intérieur, je
me suis étonné de voir un oneway étrange à cet endroit
http://www.openstreetmap.org/#map=18/48.82285/2.38027 avec donc les 2 ways
dans le même sens et qui plus est se croisent.

Quelqu'un qui connait bien l'endroit pour corriger?

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

Re: [OSM-talk-fr] OpenSolarMap...

[osm . sanspourriel]

J'oubliais alors que pour les routes j'y pensais : un toit même bien 
orienté, ou plat ne convient pas s'il y a des masques solaires (arbres, 
sommets...).

On répond quoi dans ce cas ?

La réponse n'est pas forcément la tronçonneuse ;-).
Je suppose qu'il faut répondre "bêtement", à préciser dans l'aide.

Je viens de voir (en me faisant avoir) que la surface cliquable est plus 
grande que l'icône.


Jean-Yvon


Le 09/11/2015 23:08, osm.sanspourr...@spamgourmet.com a écrit :




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

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Philippe Verdy]

On ne sait peut être pas la date de  naissance du christ mais on sait des
dates précises sur cette période.  Cela fixe les calendriers avec une date
connue précisément mêle si ce n'est pas la date du christ mais qu'on
utilise comme date commune de départ des calendriers julien et grégoriens
pour leur année 1. Par la suite pleins de dates de l'ère avant cette date
axiomatique et figée ont été définies précisément.  Ce dont on s'en fiche
alors est de savoir quand est né le christ car la on est même à 4 ou 7
années près selon les sources, et on n'est même pas sur de l'âge du christ
à sa mort alors que cette mort est datée très précisément, au moins pour le
jour du jugement car il y a aussi une incertitude sur la durée du supplice
et le jour de la descente de croix, et par la suite de celui de la
résurrection annoncée et donc du choix finalement arbitraire de la plaque
chrétienne qui a été remaniée politiquement pour menager les oppositions
avec la pâque juive mais aussi les fêtes civiles romaines du printemps.
L'année 1 à donc été fixée arbitrairement pour mettre tout le monde
d'accord plusieurs siècles après et ensuite on a rapproche avec succès les
calendriers romains avec le calendrier julien et c'est un concile qui a
tenté de décider qu'elle pouvait être l'année 1 mais les recherches
historiques de rapprochement avec les calendriers romains n'ont pas
réussi.  Il en est resté des incertitudes dd datation de toute la vie du
christ,  alors que pour le reste,  les dates du premiers siècle ainsi co
venues sont très bien établies. L'incertitude sur les dates du calendrier
romain sont sur des siècles antérieurs au premier siècle et on ne sait pas
précisément la date de fondation de Rome ni plein de dates de l'été
hellénique ou pourtant exustait déjà des fêtes pascales, non chrétiennes
forcément.

Bref l'année 0 n'est pas une question dont on se fout en histoire... Et on
est bien à moins d'une année près, avec seulement des incertitudes de
quelques jours,  notamment dans la période hivernale avant mars puisque les
romains ne dataient pas précisément les deux derniers mois de l'année.
Le 9 nov. 2015 23:26,  a écrit :

> Moi aussi ça me va.
>
> Pour plus de clarté je suis pour l'utilisation des tirets dans l'ISO 8601
> pour désigner des dates.
> Soit :
> 1001..1099 - 1492-02-12..1492-02-13
> C'est moins cabalistique.
>
> Pour la fameuse année zéro, comme vous de savez pas à 4 ans près (ou plus)
> quand le Jésus Christ a poussé son premier Christ, heu cri, donner des
> dates antérieures à une précision de +/- 1 an, on s'en fiche (pour les
> données qui nous concernent).
>
> Jean-Yvon
>
> Le 09/11/2015 17:10, Jérôme Seigneuret - jseigneuret-...@yahoo.fr a
> écrit :
>
> Si on voulait préciser une construction s'étalant du 11e siècle au 15e,
>> cela donnerait "1001..1099 - 1401..1499". Si on peut dater plus précisément
>> une date, par exemple février 1492 pour la seconde borne au lieu du simple
>> 15e siècle, cela donnerait "1001..1099 - 1492-02"
>>
>> Je trouve ça plutôt intéressant
>
>
>> Mais si la construction s'est achevée encore plus précisément le 12 ou le
>> 13 février, cela donnerait "1001..1099 - 1492-02-12..1492-02-13" (les 4
>> dates mentionnée sont toutes en format compatible ISO 8601 (lequel format
>> n'inclut aucune espace ni aucun point... mais admet qu'on puisse supprimer
>> les séparateurs "-" entre les composants année-mois-jour à condition de
>> mettre les années sur 4 chiffres minimum, donc autoriserait aussi qu'on
>> utilise pour nos intervalles: ""1001..1099 - 14920212..14920213").
>>
> Moi ça me va
>
>>
>>
>
> ___
> 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