Re: [OSM-talk-be] GR Flanders data available for mapping!

[Marc Gemis]

With a server you could also keep count of the number of relations over
time and monitor changes. That is what Wambacher does for admin boundaries.
So you will also see when people delete route relations, something that is
harder to do with Josm and Overpass. You might also monitor large changes
in the route themselves, e.g. people rerouting them without breaking them.

I have seen several people offering hardware for the Belgian community, but
nobody seems to do something with those offers.

m
Op 6 jun. 2016 23:43 schreef "Jo" :

> We're doing that in JOSM. It isn't very hard to download all relations of
> a given type for a region using Overpass and then run JOSM's validator on
> it.
>
> I then fix the problem. The validator usually reports some other problems,
> which I also resolve, then upload. The run the validator on the whole
> dataset once more, and so on.
>
> That's how I'm fixing problems with the route relations and improving the
> detail in some spots. It should become easier as we progress with the
> development.
>
> For an online tool, I don't have the resources, although it might happen I
> create something for integrating PT (and keeping it up to date) using
> PythonAnywhere.com.
>
> Jo
>
> 2016-06-06 23:02 GMT+02:00 Marc Gemis :
>
>> On Fri, Jun 3, 2016 at 1:53 PM, Jo  wrote:
>> > Darya is working on such a tool for public transport (GSoC project). I
>> don't
>> > think it would be very hard to extend it to walking and cycle routes.
>> But
>> > let's see in a month or 2 if there is time left to do that.
>> >
>>
>> Will  that be a website ?  A bit like vmarc's website for walking
>> networks or Wambacher's boundary website? It would be nice to get an
>> overview of broken relations, without having to download an area and
>> then run a "validator".
>>
>> For me, WhoDidIt is not ideal. I rather see something listing all
>> "broken" relations in an area (read Belgium)
>>
>> regards
>>
>> m
>>
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[Talk-cz] Cykloznačení - puntík se stříškou

[Marián Kyral]

Ahoj,
o víkendu jsme nedaleko Valmezu potkali cyklisty, kteří obnovovali takové 
podivné značení: červený puntík se stříškou - na fotce dole: http://map.
openstreetmap.cz/img/guidepost/20160604_095250_88.jpg

Netušíte někdo, co to je za značení?

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

[OSM-talk-fr] Osmose vs ref:FR:LaPoste

[Francois Gouget]

J'ai l'impression qu'Osmose veut mettre la référence des boites 
aux lettres sur le tag ref et non sur ref:FR:LaPoste. Or il me semblait 
que c'est ce dernier qui était préféré. En tout cas c'est lui qui est 
mentionné sur la page Wiki de ref.

https://wiki.openstreetmap.org/wiki/FR:Key:ref#Valeurs_du_projet_France


Par exemple ces deux boites aux lettres à Cachan sont toutes deux leur 
tag ref:FR:LaPoste positionné et pourtant Osmose considère qu'elles ne 
sont pas intégrées et semble vouloir leur mettre un simple tag ref :

http://osmose.openstreetmap.fr/en/map/?zoom=17=48.79155=2.34122=BFT

Ou alors qje n'ai pas bien compris comment marche l'intégration avec 
Osmose. Quelqu'un peut-il m'éclairer ?


Coté bureaux de poste je ne suis pas sûr qu'il y ait le même problème.


-- 
Francois Gouget   http://fgouget.free.fr/
May your Tongue stick to the Roof of your Mouth with the Force of a Thousand 
Caramels.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] proposta introduzione cai_scale

[Alberto Nogaro]

From: Alfredo Gattai [mailto:alfredo.gat...@gmail.com] 
Sent: lunedì 6 giugno 2016 17:20
To: talk-it@openstreetmap.org
Subject: [Talk-it] proposta introduzione cai_scale

- il cai_scale da riportare dovrebbe essere non tanto frutto di una valutazione 
personale, ma derivante dalla lettura di cio' che e' riportato sul cartello e 
dalle conoscenze delle sezioni locali.

- queste informazioni non hanno veramente IP, perche' chiunque mappando puo' 
riportare la difficolta' riportata su di un cartello, inoltre quello che si sta 
facendo internamente al CAI e' proprio dissipare possibili antiche paure sul 
"dar via" dei dati che di fatto dovrebbe essere di tutti.

- personalmente preferirei assegnarlo alla singola way (come per sac_scale) 
perche' all'interno di un itinerario, specialmente se turistico ci possono 
essere vari tratti asfaltati e/o su mulattiere per le quali non avrebbe neanche 
senso assegnarlo. Invece sui singoli tratti ha molto senso perche' si puo' 
decidere di percorrere pezzi di questo o quel sentiero e fare degli anelli di 
difficolta' bassa invece di percorrerne uno intero che ha tratti piu' 
difficili. La difficolta' piu' alta dell' intera relation puo' essere ricavata 
dalla way piu' difficile o al limiti per chi vuole non lasciare nulla al caso, 
al limite la riporta anche sulla relation.




Correggimi se sbaglio, mi sembra che la classificazione di un itinerario 
dipenda anche dall'impegno fisico complessivo richiesto.  Ad esempio un 
itinerario impegnativo perché  molto lungo potrebbe avere una classificazione 
superiore a quella dei singoli tratti. Se così fosse, non sarebbe possibile 
ricavarlo dalla via più difficile.

Trattandosi di classificazioni ufficiali, penso che i tag di difficoltà CAI 
andrebbero inseriti solo da chi ha accesso alla documentazione relativa. La 
difficoltà indicata sul cartello, non distingue le difficoltà dei singoli 
tratti verso la destinazione indicata. Dunque non andrebbe inserita da chi non 
conosce eventuali suddivisioni tra tratti di diversa difficoltà. Sono invece 
favorevole alla inserzione da parte di chiunque nella descrizione del cartello 
(nodo tourism=guidepost o relazione di tipo destination_sign). Sulla base di 
questa proposta [1], si potrebbe pensare ad inserirla in un tag del tipo 
destination: cai_scale.





Ultimo, date un'occhiata ad un inizio di localizzazione fatta da su 
waymarkedtrails facendogli modificare leggermente le bandierine di osmc:symbol

http://hiking.waymarkedtrails.org/#?map=16!44.0761!9.8219

La gentilissima Sara Hoffman l'ha realizzato una volta visti gli esempi di 
bandierine CAI che gli ho mandato e vista la massa critica di relazioni che 
abbiamo inserito in questa zona. Piano piano magari riusciremo ad introdurre 
anche un rendering con la scala di difficolta'.




Molto bella la bandierina con la fascia bianca allargata. Ho visto che il tag 
osmc è standard. Quale tag fa scattare l'uso della bandierina modificata? Una 
volta terminate le definizioni per il rendering personalizzato, sarebbe bene 
che venisse documentato da Sarah sulla pagina dedicata [2]

[1] http://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details
[2] http://hiking.waymarkedtrails.org/help/rendering/hikinglocal



Ciao,
Alberto


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

Re: [OSM-talk-be] WMS layer SPW(Wallonie) PICC disponible dans JOSM est obsolete

[lionel bulpa]

[FR]Bonjour, 
Il me semblait qu'on ne pouvait pas copier ces données dans OSM, est-ce que ce 
n'était pas le message qui est passé il y a quelques mois?
Lionel
[EN]Hello,It seems to me that we could not copy the data into OSM, is that this 
was not the message that is passed in the last few months?Lionel
[NL]Hallo,Het lijkt mij dat we niet de gegevens in OSM kan kopiëren, is dat dit 
was niet de boodschap die wordt doorgegeven in de laatste paar maanden?Lionel

From: a.pirard.pa...@gmail.com
To: talk-be@openstreetmap.org
Date: Mon, 6 Jun 2016 03:09:55 +0200
Subject: Re: [OSM-talk-be] WMS layer SPW(Wallonie) PICC disponible dans JOSM 
est obsolete


  

  
  
On 2016-06-06 02:43, André Pirard
  wrote:



  Please do JOSM>Imagery>Imagery Preferences>Available
  default entries>refresh (whirling arrows)  and

  Activate : BE : SPW(allonie) PICC numerical imagery

  OK

  and use the PICC layer as before.


Je constate qu'il n'y a pas de noms de rues et qu'il y a des
ridicules colliers de boules de coton.

D'autre part, j'ai lu qu'ils ont (par exemple) retiré les points de
références bien utiles pour vérifier le positionnement.

Je vais vérifier demain si tout est complet.

Si oui, je chercherai un calque supplémentaire contenant les noms.

Ce n'est pas plus mal, car les noms masquaient souvent le centre de
la voie.



En attendant, pourriez-vous repérer de semblables autres
inconvénients et améliorations.



Cordialement,





  

  André.

  



  


___
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] GR Flanders data available for mapping!

[Jo]

We're doing that in JOSM. It isn't very hard to download all relations of a
given type for a region using Overpass and then run JOSM's validator on it.

I then fix the problem. The validator usually reports some other problems,
which I also resolve, then upload. The run the validator on the whole
dataset once more, and so on.

That's how I'm fixing problems with the route relations and improving the
detail in some spots. It should become easier as we progress with the
development.

For an online tool, I don't have the resources, although it might happen I
create something for integrating PT (and keeping it up to date) using
PythonAnywhere.com.

Jo

2016-06-06 23:02 GMT+02:00 Marc Gemis :

> On Fri, Jun 3, 2016 at 1:53 PM, Jo  wrote:
> > Darya is working on such a tool for public transport (GSoC project). I
> don't
> > think it would be very hard to extend it to walking and cycle routes. But
> > let's see in a month or 2 if there is time left to do that.
> >
>
> Will  that be a website ?  A bit like vmarc's website for walking
> networks or Wambacher's boundary website? It would be nice to get an
> overview of broken relations, without having to download an area and
> then run a "validator".
>
> For me, WhoDidIt is not ideal. I rather see something listing all
> "broken" relations in an area (read Belgium)
>
> regards
>
> m
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-it] proposta introduzione cai_scale

[Alberto]

+1
cai_scale mi sembra sensato, per avvicinare il CAI ad OSM e per riportare un 
dato che si trova fisicamente sui cartelli.
Però per la compatibilità con il resto del mondo è indispensabile che venga 
mantenuta la sac_scale: bisognerà sottolinearlo bene nella pagina del wiki 
dedicata alla cai_scale.

-1 per ripetere la classificazione (cai o sac) sulla relazione.
E' inevitabile che facendo gli aggiornamenti della scala sui vari tratti prima 
o poi qualcuno si dimenticherà di aggiornare la scala sulla relazione e i dati 
non saranno più coerenti. Molto meglio ricavare la scala automaticamente dal 
tratto più difficile.
Inizialmente se il dato cai_scale è disponibile solo per l'intera relazione, lo 
si può assegnare così, ma appena si avranno a disposizione i dati per i vari 
tratti, la scala sulla relazione sarà bene toglierla.

Alberto


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


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

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[osm . sanspourriel]

Le 2016-06-06 à 20:27, Éric Gillet - gill3t.3ric+...@gmail.com a écrit :
Le 6 juin 2016 à 12:45, Christian Quest > a écrit :


C'est très machine friendly mais par du tout human friendly... et
pour l'instant les contributeurs sont plus des humain que des
machines ;)


Pas sûr, en plus des problèmes de performance et de complexité 
(relative) de mise en oeuvre, devoir dépendre sur une base de données 
externe ajoute des contraintes en terme de disponibilité, et pérennité 
d'OSM.


Mais oui je conçois que l'idée soit agréable dans son concept :)
Oui, assez d'accord avec Éric et Cie. Mais on ne dépend pas forcément de 
la disponibilité de Wikidata.


D'abord un aparté. /Ils arrivent à faire une vidéo de présentation 
 sans expliquer l'origine d'enedis (sans 
accent, contrairement à ÉNErgie DIStribution), sans expliquer comment ça 
se prononce. Par défaut en français comme euneudix. Super pour les moins 
capables qui se feront taxer de neuneu dix (tu es un enedis : tu es un 
neuneu//^dix //). Si ça se prononce comme Haine//^Dix //, pas beaucoup 
mieux.//
//Je trouve ce pubeux extraordinaire car faire un effet de dominos alors 
que l'écroulement du réseau (ce que doit absolument éviter Enedis) se 
fait par effet domino, privant par exemple 10 millions de Français et 
seulement 8 d'Allemands parce qu'un gestionnaire de réseau a coupé 
volontairement et après prévenance, notamment du principal producteur 
appartenant au même groupe et qui pourtant a produit sans en tenir 
compte, entraînant cette effet domino. Fort le mec sachant qu'en France 
aussi un producteur (EDF) et un opérateur de réseau (Enedis) font partie 
de même groupe... Et montrer la continuité de service au delà du 
continent alors qu'EDF SA et ERDF sont en pleine consanguinité à l'Ile 
de Sein (ERDF faisant des réunions avec et uniquement avec EDF), chapeau 
bas !/

Fin de l'aparté.

Alors nom direct ou pas ?
Nom direct = simplicité (et effectivement je suis pour utiliser en 
operator ou brand les noms effectivement pratiqués, donc SNCF Réseau pas 
Société Nationale des Chemins de fer Français Réseau)

Wiki data = stabilité ?

Je vois que SNCF Réseau a son wikidata (Q21605526 
).
Bien, mais je vois qu'il existe en deux langues (FR et EN), a une petite 
description dans les mêmes mais a des pages wikipédia en FR et... DE.
Et cet EPIC est défini comme " établissement public à caractère 
industriel et commercial (Q3591583 
) "
Les noms alternatifs (comme EPIC) sont mis en vrac alors que sous OSM ce 
serait un short_name.


Il me semble intéressant d'avoir des description de Wikidata dans OSM.

C'est à dire que les références vers des brands, operator et quelques 
autres seraient des liens vers des nœuds ou relations OSM de type Wikidata.
Je ne sais si on doit imposer une géométrie (sinon on risque de casser 
le modèle) ou considérer non que ce sont des nœuds mais des relations 
spéciales (couples attributs/valeurs sans membres (forcément ?) mais 
avec un attribut wikidata) ?


Bien-sûr l'utilisateur lambda doit pouvoir écrire SNCF Réseau ou Enedis, 
c'est à l'éditeur de faire la correspondance.

En fonction du contexte le choix peut être fortement guidé.
Par exemple l'objet Q3587594 (Enedis) doit avoir
name=Enedis
wikidata=Q3587594
old_name=ERDF
old_name:1=Electricité Réseau Distribution France
old_name:2=EDF
old_name:3=Electricité de France
(je sais ERDF et EDF sont des anciens short_name, 
short_name:-2016-06-01=ERDF serait toujours faux mais plus précis).


Vous aurez compris, je vois plus ces objets par création via intégration 
plus que par import brut.
En gardant la date de dernier import on peut facilement avoir des outils 
pour les mettre à jour (facilement : je parle du niveau conceptuel ;-)).


On peut même faire référence la liste des gares bretonnes en indonésien 
! Q3249799 .
Juste pour dire que les wikidata qui nous intéressent ne sont qu'une 
partie de ce qui existe : un import massif n'aurait pas de sens.
De même un remplacement systématique par des relations (comme un 
renommage systématique) doit être surveillé : import versus intégration.


Plusieurs avantages :
- on reste en OSM, sans dépendance permanente vers la base Wikidata.
- on garde notre modèle (pas de noms en vrac, mais des noms par langue, 
des noms locaux, des noms courts, des noms internationaux...) donc les 
outils suivent (surtout si la valeur est une référence vers une relation).


Peut-être qu'il faut avoir des ref:rel; brand:rel pour savoir que la 
valeur est une relation dont le nom doit être affiché.


Exemple d'affichage sous OSM de la sous-station : 
http://www.openstreetmap.org/node/1739065627

Actuel :
name  
Fontaine de Kereven
operator 

Re: [OSM-talk-be] GR Flanders data available for mapping!

[Marc Gemis]

On Fri, Jun 3, 2016 at 1:53 PM, Jo  wrote:
> Darya is working on such a tool for public transport (GSoC project). I don't
> think it would be very hard to extend it to walking and cycle routes. But
> let's see in a month or 2 if there is time left to do that.
>

Will  that be a website ?  A bit like vmarc's website for walking
networks or Wambacher's boundary website? It would be nice to get an
overview of broken relations, without having to download an area and
then run a "validator".

For me, WhoDidIt is not ideal. I rather see something listing all
"broken" relations in an area (read Belgium)

regards

m

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

Re: [OSM-talk-fr] [OverpassTurbo] Obtenir une seule route à partir de ways?

[Shohreh]

J'ai trouvé un work-around un peu laborieux mais qui a résolu le problème:

https://www.google.com/maps/d/viewer?mid=1XkoF58XBbEL-eSq0u450mEEWaxo

1. Utiliser OverpassTurbo pour chacune des routes (relations):
rel(1266651);
/*added by auto repair*/
(._;>;);
/*end of auto repair*/
out; 

2. Exporter en KML

3. Utiliser GPSVisualizer > Google Earth (KML) > Track options > Advanced :
Merge all tracks = Yes
http://www.gpsvisualizer.com/map_input?form=googleearth

4. Importer chaque KML dans Google My Maps, renommer Tracks et supprimer
Waypoints



--
View this message in context: 
http://gis.19327.n5.nabble.com/OverpassTurbo-Obtenir-une-seule-route-a-partir-de-ways-tp5874852p5874877.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: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Landry Breuil]

2016-06-06 15:34 GMT+02:00 FR :
> Le 06/06/2016 10:50, g...@laposte.net a écrit :
>>
>> Autre remarque, je trouve regrettable de noter en source [année de
>> reference = 2016] après la mention "IGN France" alors que les photos
>> datent parfois de plusieurs années. (mais je ne vois pas comment
>> retrouver  l’année vraie des photos)
>>
> Bonjour
> Osmose n'aime pas "source=BDOrtho IGN 2016"
> message d'erreur "tag source illégal ou incomplet"

Oui, j'ai vu ca sur certains objets taggués avec
'source=Orthophotographie CRAIG/IGN 2013'.. peut-etre des restes du
passé ou 'source=.*IGN.*' était considéré illégal dans les analyses
osmose ?

Landry

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

Re: [Talk-us] Best practices for dealing with old TIGER tags?

[Mark Wagner]

On Sun, 5 Jun 2016 13:21:07 -0700
Dion Dock  wrote:


> I think the rural residential roads are either “highway=service”,
> “highway=track” or “highway=path”.  I think “highway=residential”
> should always have a name.  Service might or might not have a name,
> same for path and track.

You must be driving on a different set of roads than me.  Consider
South Bank Road (OSM:
https://www.openstreetmap.org/#map=15/47.8602/-117.6751, Google:
https://www.google.com/maps/@47.8555045,-117.6814056,14z).  It doesn't
connect anywhere to anywhere, so it's not tertiary or above, but
"highway=service" doesn't seem appropriate for a road that provides
access to about a hundred scattered houses and two little-known parks,
and "highway=track" seems wrong for eight miles of paved two-lane
public road.

Or if that seems too built-up, how about Glenwood Road
(OSM:https://www.openstreetmap.org/#map=14/46.9380/-117.2812,
Google: https://www.google.com/maps/@46.9391634,-117.2896051,14z).
Four miles of high-quality two-lane gravel road, providing access to
some farms and a home or two.

There's a definite need for a road level between "this is how you
travel from town A to town B" and "this is how you make your final
approach to your destination".  "highway=unclassified" seems like it
works well there.

-- 
Mark

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

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[Éric Gillet]

Le 6 juin 2016 à 12:45, Christian Quest  a écrit :

> Le 06/06/2016 à 12:30, Nicolas Dumoulin a écrit :
>
>> Salut,
>>
>> Le Fri, 3 Jun 2016 19:28:51 +0200,
>> François Lacombe  a écrit :
>>
>>> Quid de proposer au DWG de faire une migration en masse ?
>>> Plutôt facile à réaliser : overpass => query sur operator=ERDF => JSOM
>>> ctrl+A => operator=Enedis => Upload
>>>
>>> Le principal enjeu est l'information de la communauté et la mise à
>>> jour des scripts de consommation.
>>>
>> Le cas se présente régulièrement : comment gérer le renommage en masse
>> sans casser les dépendances des outils aux noms dans la base OSM.
>> Et là, suite à la fantastique présentation de wikidata à Clermont, je
>> me dis et je vous transmets :
>> Si on mettais operator=wikidata:Q3587594 plutôt que Enedis ?
>> https://www.wikidata.org/wiki/Q3587594
>>
>> Ça implique aux outils de représentation d'utiliser wikidata, et je
>> suis d'accord ça alourdi un peu le processus.
>> Mais sinon, ça simplifierai beaucoup de chose :-)
>>
>> C'est dans la même veine que l'idée de Jean-Louis lors de sa
>> présentation : déplacer dans wikidata les histoires de liste de noms
>> alternatifs à rallonge. Wikidata est conçu pour ça, et on est vite
>> limité dans OSM avec nos quelques variantes de *_name et name_*.
>>
>> C'est pas évident à mettre en place, mais je trouve cela très séduisant.
>>
>>
> C'est très machine friendly mais par du tout human friendly... et pour
> l'instant les contributeurs sont plus des humain que des machines ;)
>

Pas sûr, en plus des problèmes de performance et de complexité (relative)
de mise en oeuvre, devoir dépendre sur une base de données externe ajoute
des contraintes en terme de disponibilité, et pérennité d'OSM.

Mais oui je conçois que l'idée soit agréable dans son concept :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] proposta introduzione cai_scale

[Alfredo Gattai]

Esatto, la seconda quindi nel caso lo si ricavi da un cartello non puo' che
andare sulla relazione in attesa di migliori informazioni dal CAI
direttamente

2016-06-06 19:41 GMT+02:00 girarsi_liste :

> Il 06/06/2016 19:38, Aury88 ha scritto:
> > non ho capito una cosa: si parla del fatto che chiunque può riportare la
> > difficoltà riportata sul cartello...non ho capito se però quel cartello è
> > riferito al  singolo tratto o all'intero sentiero
> >
>
> La seconda nel caso del CAI/SAT.
>
>
> --
> Simone Girardelli
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] proposta introduzione cai_scale

[Alfredo Gattai]

Grazie Dario per il link, e' esattamente quello a cui alludevo, anche
all'interno del CAI le esigenze vanno modificandosi e quindi sempre piu'
spesso si avra' a disposizione una classificazione del tratto.

Direi pur riprendendo quello che scrive Simone di non farne una regola
troppo restrittiva

cai_scale --> puo' stare sulla relazione anche se potrebbe essere ricavato
automaticamente (e quindi come dice Aurelio aggiornarsi nel caso un tratto
cambi)

sac_scale --> sui singoli tratti di way. ma addizionalmente laddove ci sia
l'informazione si puo' aggiungere anche cai_scale per singolo tratto.

>Però, contraddicendomi, il tag proposto, va piuttosto in là dei 4/5
>codici CAI, questo mi sembra più esaustivo, invito l'utente che ha
>proposto il tag a corredarlo di foto, per quanto un pò fuorvianti, sono
>comunque di aiuto per la descrizione, ovvio che le foto più sono
>realistiche e vicine al valore del tag, più sono descrittive quanto il
>valore stesso.

Era mia intenzione farlo, devo fare un po' di ricerche ma mi sembra
necessario

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

Re: [Talk-it] proposta introduzione cai_scale

[girarsi_liste]

Il 06/06/2016 19:38, Aury88 ha scritto:
> non ho capito una cosa: si parla del fatto che chiunque può riportare la
> difficoltà riportata sul cartello...non ho capito se però quel cartello è
> riferito al  singolo tratto o all'intero sentiero
> 

La seconda nel caso del CAI/SAT.


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



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

Re: [Talk-it] proposta introduzione cai_scale

[Aury88]

premesso che non sono un esperto della classificazione CAI ne di altri tipi
di classificazione (argomento che comunque vorrei approfondire se trovo la
documentazione,
Premesso che non sono un fan della ridondanza dei tag, 
posto che se, come mi sembra di capire, questo tipo di classificazione non è
direttamente ricavabile da altri metodi di classificazione già utilizzati su
osm,
per quanto possa valere il mio parere di inesperto sono favorevole
all'introduzione di questo tag visto che comunque non mi sembra interferisca
con altri tag in utilizzo.
sono anche molto favorevole all'applicazione del value riferito alla
difficoltà del singolo tratto (ma devo capire cosa si intenda per tratto...)
sono un po' meno favorevole all'applicazione del medesimo tag sulla
relazione del sentiero...imho dovrebbe essere una cosa ricavata in
automatico appunto dal valore massimo del tag tra i membri della relazione ;
così facendo applicando un cambiamento al singolo tratto si applica
eventualmente automaticamente il cambiamento a livello di sentiero di cui fa
parte.

non ho capito una cosa: si parla del fatto che chiunque può riportare la
difficoltà riportata sul cartello...non ho capito se però quel cartello è
riferito al  singolo tratto o all'intero sentiero

 



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/proposta-introduzione-cai-scale-tp5874853p5874870.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-it] proposta introduzione cai_scale

[Dario Zontini]

Scusate,  vi mando il link diretto

http://www.sat.tn.it/sns/12/modulistica/scheda_iscrizione_modifica_sentiero.pdf

Dario Zontini

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

Re: [Talk-it] proposta introduzione cai_scale

[Dario Zontini]

Vi segnalo che sulla modulistica della Sat di Trento [1] (modello B.  A
fine modello ci sono delle note di spiegazione) ,  quando si chiede di
accatastare un nuovo sentiero viene chiesto di indicare la difficoltà su
vari tratti tra 2 luoghi di posa. Poi nelle pubblicazioni ufficiali la
difficoltà del sentiero è definita sull'intero sentiero.

[1] http://www.sat.tn.it/default.aspx?fn=loadarea=451

Dario Zontini

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

[Talk-it-trentino] La pagina stats/user su wiki OSM.

[girarsi_liste]

Chiedo, questa pagina:

http://www.openstreetmap.org/stats/data_stats.html

Come link nella pagina principale della wiki di osm, che fine ha fatto?

Non lo vedo più oppure è sotto altro nome?

grazie.



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



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

Re: [Talk-it] proposta introduzione cai_scale

[girarsi_liste]

Il 06/06/2016 18:59, Alfredo Gattai ha scritto:
> Mettiamola cosi', e' vero come dice Luca che il CAI assegna la difficolta'
> in base al tratto piu' difficile quindi per comodita' e brevita' assegnarlo
> alla relazione risolve molto problemi, ma e' altrettanto vero che i tempi
> cambiano, le tipologie di percorsi pure e quindi direi che se uno ha tempo
> e voglia assegnarlo anche alle singole way non guasta.
> 
> Aihme' Alessandro, i "concetti rivoluzionari" che devo affrontare con il
> CAI sono ben altri ma conto sull'effetto "supercazzola" :-)
> 
> Scherzi a parte, stiamo trovando terreno fertile, anche da parte di quelli
> piu' in la con gia anni, direi che la piccola palla di neve sta cominciando
> a rotolare, contiamo di farla diventare una valanga.
> 
> Alfredo
> 
> 


Guardate che non fa male cancellare parte del commento se non
interessa!! (onde evitare troppi listati lunghi per niente) :) (non
offendetevi eh!).

Miei 2 cents.

Parlare di sac_scale e cai_scale, va bene se sui tratti si mette il
sac_scale, mentre sulla relazione si mette il cai_scale.

Il motivo è principalmente legato al fatto che il sac_scale è
riconosciuto internazionalmente da tutti ed ha senso secondo me per la
valutazione del singolo tratto, mentre il cai_scale, vale appunto solo
per il suolo italiano e che sappia io, le altre nazioni non contemplano
il tipo di scala CAI e comunque è legato ai valori CAI.

Però, contraddicendomi, il tag proposto, va piuttosto in là dei 4/5
codici CAI, questo mi sembra più esaustivo, invito l'utente che ha
proposto il tag a corredarlo di foto, per quanto un pò fuorvianti, sono
comunque di aiuto per la descrizione, ovvio che le foto più sono
realistiche e vicine al valore del tag, più sono descrittive quanto il
valore stesso.

Quindi riassumendo il tutto, per adesso come inizio, come già detto da
qualcun'altro, chiedo scusa se non ricordo chi:

sac_scale --> sui singoli tratti di way.

cai_scale --> sulla relazione al posto del sac_scale, salvo decisioni
diverse.


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



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

Re: [OSM-talk-be] Import of 2000 DAE in Belgium (Defibrillators / > Défibrillateurs)

[Marc Gemis]

Je mag natuurlijk altijd zelf de defribilator mappen in OSM en je foto
prive houden.
Zie  http://wiki.openstreetmap.org/wiki/Tag:emergency%3Ddefibrillator
voor de tagging.

mvg

m

2016-06-06 9:28 GMT+02:00 Philippe Casteleyn :
> Eindelijk iemand die niet al een wildeman mapt zodra hij gegevens tegenkomt.
>
> Ik heb gisteren een defibrillator tegengekomen in Steenokkerzeel.
> http://www.mapillary.com/map/im/7RmuSqkA2GO9obPesXY8GA/photo
>
> Ik ben vergeten een goede foto te maken.   Mapillary foto's duren immers 12
> seconden om te laden en de kwaliteit is slecht. Dat is wel extra werk.
> Zou zoiets niet in Flickr kunnen getagd worden ?
> Ik heb eigenlijk zonder ze te willen verzamelen al veel defibrillatoren in
> Mapillary gefotografeerd.
> In de toekomst zullen we Mapillary kunnen trainen om ze te herkennen.
>
> De DAE in het Pachecoinstituut Grootgodshuisstraat 7A, 1000 Brussel  staat
> binnen naast het onthaal en die heb ik dan maar niet gefotografeerd.   Ik
> had geen zin om een hele uitleg te doen.
>
> Ph Casteleyn
> Dahliastraat 16
> 2800 Mechelen
> animals.slippers.loaders
> gsm 0486 516261
> Ctrl+v
>
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [Talk-GB] OS open map local polygon accuracy

[roger]

I was thinking more of the woodland polygons, and the linear features. They are a lot harder to run a complex feature simplification algorithm on than the building outlines.  My test area is Warton Crag in north Lancashire. There is a lot of stuff there that looks like it has been hand traced from OS open street view rasters, which I suspect have been translated to WGS84 without using the OSTN02 data.
Roger
On 6 Jun 2016 5:35 pm, Ed Loach  wrote:The shapes themselves aren’t particularly accurate, if you look at say building outlines and compare to Bing. It shouldn’t take long to find a non-rectangular building on Bing which has been approximated to rectangular in OS Open Map Local Ed From: roger@beardandsandals.co.uk [mailto:roger@beardandsandals.co.uk] Sent: 06 June 2016 14:45To: talk-gb@openstreetmap.orgSubject: [Talk-GB] OS open map local polygon accuracy Hi,I have been looking at the OS openmap local vector dataset. I noticed that the coordinates in there are centimetre level accuracy. I am speculating how the OS made this dataset a "nominal viewing scale" of  1:1. Scales are somewhat irrelevant to vector data. Have they degraded the geometry points by thinning or averaging, or is the data still at survey level accuracy? I have some old (paid for) OS master map data. It would be interesting to compare the polygons in there with the the openmap local ones. But before I search my loft for the disc, has anyone already done this?Roger___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] proposta introduzione cai_scale

[Alfredo Gattai]

Mettiamola cosi', e' vero come dice Luca che il CAI assegna la difficolta'
in base al tratto piu' difficile quindi per comodita' e brevita' assegnarlo
alla relazione risolve molto problemi, ma e' altrettanto vero che i tempi
cambiano, le tipologie di percorsi pure e quindi direi che se uno ha tempo
e voglia assegnarlo anche alle singole way non guasta.

Aihme' Alessandro, i "concetti rivoluzionari" che devo affrontare con il
CAI sono ben altri ma conto sull'effetto "supercazzola" :-)

Scherzi a parte, stiamo trovando terreno fertile, anche da parte di quelli
piu' in la con gia anni, direi che la piccola palla di neve sta cominciando
a rotolare, contiamo di farla diventare una valanga.

Alfredo


2016-06-06 18:20 GMT+02:00 Alessandro Palmas :

> Il 06/06/2016 17:49, Luca Delucchi ha scritto:
>
>> 2016-06-06 17:19 GMT+02:00 Alfredo Gattai :
>>
>>> - personalmente preferirei assegnarlo alla singola way (come per
>>> sac_scale)
>>> perche' all'interno di un itinerario, specialmente se turistico ci
>>> possono
>>> essere vari tratti asfaltati e/o su mulattiere per le quali non avrebbe
>>> neanche senso assegnarlo. Invece sui singoli tratti ha molto senso
>>> perche'
>>> si puo' decidere di percorrere pezzi di questo o quel sentiero e fare
>>> degli
>>> anelli di difficolta' bassa invece di percorrerne uno intero che ha
>>> tratti
>>> piu' difficili. La difficolta' piu' alta dell' intera relation puo'
>>> essere
>>> ricavata dalla way piu' difficile o al limiti per chi vuole non lasciare
>>> nulla al caso, al limite la riporta anche sulla relation.
>>>
>>> questo non sono del tutto sicuro, ma solitamente la classificazione di
>> un sentiero non è la stessa per tutto il tragitto?
>> Mi sembrava di aver visto così su alcuni libri CAI
>>
>>
> La metterei senz'altro sulla relazione, ovviamente col grado della parte
> più difficile. Sul singolo tratto però mi trovo d'accordo; sino ad ora si
> lavorava col cartaceo quindi era normale avere una singola indicazione,
> pensiamo però ad un sentiero che ha diverse tratte e solo la finale ha
> difficoltà maggiori: un'escursionista può decidere di percorrere solo il
> tratto facile. Se poi uno lo vuole percorrere tutto vedrà la massima
> difficoltà segnata nella relazione.
>
> Però Alfredo, non è forse un concetto troppo rivoluzionario per il CAI? :-)
>
> Alessandro Ale_Zena_IT
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] OS open map local polygon accuracy

[Ed Loach]

The shapes themselves aren’t particularly accurate, if you look at say building 
outlines and compare to Bing. It shouldn’t take long to find a non-rectangular 
building on Bing which has been approximated to rectangular in OS Open Map Local

 

Ed

 

From: ro...@beardandsandals.co.uk [mailto:ro...@beardandsandals.co.uk] 
Sent: 06 June 2016 14:45
To: talk-gb@openstreetmap.org
Subject: [Talk-GB] OS open map local polygon accuracy

 

Hi,

I have been looking at the OS openmap local vector dataset. I noticed that the 
coordinates in there are centimetre level accuracy. I am speculating how the OS 
made this dataset a "nominal viewing scale" of  1:1. Scales are somewhat 
irrelevant to vector data. Have they degraded the geometry points by thinning 
or averaging, or is the data still at survey level accuracy? I have some old 
(paid for) OS master map data. It would be interesting to compare the polygons 
in there with the the openmap local ones. But before I search my loft for the 
disc, has anyone already done this?

Roger

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

Re: [Talk-it] proposta introduzione cai_scale

[Alessandro Palmas]

Il 06/06/2016 17:49, Luca Delucchi ha scritto:

2016-06-06 17:19 GMT+02:00 Alfredo Gattai :

- personalmente preferirei assegnarlo alla singola way (come per sac_scale)
perche' all'interno di un itinerario, specialmente se turistico ci possono
essere vari tratti asfaltati e/o su mulattiere per le quali non avrebbe
neanche senso assegnarlo. Invece sui singoli tratti ha molto senso perche'
si puo' decidere di percorrere pezzi di questo o quel sentiero e fare degli
anelli di difficolta' bassa invece di percorrerne uno intero che ha tratti
piu' difficili. La difficolta' piu' alta dell' intera relation puo' essere
ricavata dalla way piu' difficile o al limiti per chi vuole non lasciare
nulla al caso, al limite la riporta anche sulla relation.


questo non sono del tutto sicuro, ma solitamente la classificazione di
un sentiero non è la stessa per tutto il tragitto?
Mi sembrava di aver visto così su alcuni libri CAI



La metterei senz'altro sulla relazione, ovviamente col grado della parte 
più difficile. Sul singolo tratto però mi trovo d'accordo; sino ad ora 
si lavorava col cartaceo quindi era normale avere una singola 
indicazione, pensiamo però ad un sentiero che ha diverse tratte e solo 
la finale ha difficoltà maggiori: un'escursionista può decidere di 
percorrere solo il tratto facile. Se poi uno lo vuole percorrere tutto 
vedrà la massima difficoltà segnata nella relazione.


Però Alfredo, non è forse un concetto troppo rivoluzionario per il CAI? :-)

Alessandro Ale_Zena_IT

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

[Talk-at] Wichtige Frage

[en...@astridsteinbrecher.com]

Liebe Openstreetmap-Community,
ich habe mit 2 Frauen das Projekt der "Drachenaugenplätze" ins Leben gerufen 
(pdf im Anhang). Kurz zusammengefasst geht es um die Errichtung kleiner 
Kraftplätze in der freien Natur (aus Steinen, Ästen, natürlichen Fundstücken 
und diversen anderen kleinen persönlichen Schmuckstücken), über die sich 
Menschen in der ganzen Welt verbinden können. Daher war uns die Markierung 
solcher Plätze auf einer digitalen Weltkarte sehr wichtig. Ein Freund von mir  
hat mir die Openstreetmap empfohlen, und wir haben die ersten Dragoneyeplaces 
schon editiert. Nun hat mich ein Administrator über Openstreetmap angesprochen, 
was es mit den Plätzen auf sich hat und mir empfohlen, das Projekt erstmal zur 
Diskussion zu stellen.
Das tu ich hiermit und entschuldige mich, falls ich in meiner Begeisterung für 
die Openstreetmap voreilig gehandelt habe.Ich würde mich sehr freuen, wenn Ihr 
unser Projekt unterstützen würdet. Wir haben keinerlei politische oder 
religiöse Gesinnung, es geht uns um einen sehr universellen verbindenden 
Charakter.
Herzliche Grüße, Astrid Steinbrecher mit Barbara und Barbara___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-it] proposta introduzione cai_scale

[Luca Delucchi]

2016-06-06 17:19 GMT+02:00 Alfredo Gattai :
> Ciao,
>

ciao Alfredo,
scusa se non ho risposto all'altra

> mi riallaccio ad un thread partito da Marco Barbieri riguardo l'introduzione
> della scala di difficolta' dei sentieri in uso al CAI. Praticamente direi
> che i vari argomenti sono stati sviscerati tutti e ad occhio mi pare che non
> ci sia una particolare opposizione ad introdurlo ovviamente con tutti i pro
> ed i contro relativi.
>
> In quanto membro attivo di una commisione sentieri del CAI (La
> Spezia-Liguria) nonche' mappatore OSM e grande sostenitore del bisogno del
> CAI di contribuire attivamente alla mappatura di sentieri e rifugi in OSM,
> volevo dare il mio contributo.
>
> Per cominciare sono andato avanti con la proposal page
>
> http://wiki.openstreetmap.org/wiki/Proposal_process/cai_scale
>
> E' in draft, vi sarei grato se la visitaste, commentaste e correggeste cio'
> che ritenete opportuno prima che vada avanti con la procedura.
>

letta e mi sembra sensata,

>
> - personalmente preferirei assegnarlo alla singola way (come per sac_scale)
> perche' all'interno di un itinerario, specialmente se turistico ci possono
> essere vari tratti asfaltati e/o su mulattiere per le quali non avrebbe
> neanche senso assegnarlo. Invece sui singoli tratti ha molto senso perche'
> si puo' decidere di percorrere pezzi di questo o quel sentiero e fare degli
> anelli di difficolta' bassa invece di percorrerne uno intero che ha tratti
> piu' difficili. La difficolta' piu' alta dell' intera relation puo' essere
> ricavata dalla way piu' difficile o al limiti per chi vuole non lasciare
> nulla al caso, al limite la riporta anche sulla relation.
>

questo non sono del tutto sicuro, ma solitamente la classificazione di
un sentiero non è la stessa per tutto il tragitto?
Mi sembrava di aver visto così su alcuni libri CAI

>
> Alfredo
>


-- 
ciao
Luca

www.lucadelu.org

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

Re: [Talk-de] zur Info: Bicycle=yes/designated als Anzeige Benutzungspflicht aufgeben

[Florian Lohoff]

On Sun, Jun 05, 2016 at 04:55:00PM +0200, Joerg Fischer wrote:
> rainerU wrote:
> 
> > z.B. rot dargestellt auf anderen Karten grün. Auch
> > Navigationsprogramme wie OsmAnd und BRouter machen das so.
> 
> Osmand? Definitiv: Nein. Osmand stellt Pfade als schwarze Strichlinie dar,
> egal ob da ein cycleway=designated dran hängt.  Ich stand heute erst wieder
> in der Pampa und hab mich geärgert das ich nicht erkennen kann ob ein Weg
> mit dem Rad befahrbar ist oder nicht weil ihn ein Verfechter dieses
> merkwürdigen Taggings als Pfad erfasst hat.

Alle Garmin Geräte haben IIRC zu wenige Klassen um das
auseinanderzubekommen.

Osmand ist nicht die welt.

Ich halte path für eine echt richtig doofe idee. Ausprobiert - Chaos
veranstaltet - aufräumen dauert länger ...

Flo
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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

Re: [OSM-talk-fr] Inondations dans le Centre et fermeture d'autoroutes

[Yves Pratter]

> Le 2 juin 2016 à 22:15, osm.sanspourr...@spamgourmet.com a écrit :
> 
> Le lieu donné ne comportait pas de données, de plus le permalien ne se 
> rappelle pas de cocher Tidal Scale dans View.
> 
> 
J’ai signalé le bug, il est quasiment corrigé (il manque juste un 
rafraîchissement de la couche à faire. Pour cela déplacez légèrement la carte 
et tout s’affiche correctement).

—
Yves

https://github.com/OpenSeaMap/online_chart/issues/90 

https://github.com/OpenSeaMap/online_chart/issues/91 



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

Re: [Talk-de] zur Info: Bicycle=yes/designated als Anzeige Benutzungspflicht aufgeben

[Martin Koppenhoefer]

Am 6. Juni 2016 um 13:49 schrieb Joerg Fischer :

> > Stimmt nicht, Joachim hat das doch vor 6 Tagen beantwortet, und ja, es
> gibt
> > diese Anwendung, es ist sogar die Standardanwendung (OSM Karte).
>
> Lies doch mal die Threads in denen Du schreibst vollständig.




mache ich normalerweise durchaus. Meine Einschätzung ist, das highway=path
geht nicht mehr weg, man wird sich damit arrangieren müssen, auch wenn man
selber andere tags bevorzugt. Bringt nichts, sich da drüber aufzuregen.

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

[OSM-ja] SotM Japan 2016のスケジュールについて

[Satoshi IIDA]

いいだ＠SotM Japan実行委員会帽子です。

5月中に行っていた発表公募ですが、
先日、締め切りを行い、いま公募いただいた内容の確認と、
スケジュールの組み立てを行っています。

https://stateofthemap.jp/2016/

今週末くらいを目標に、
当日スケジュールが立てられたらいいなー、と思っています。
「当日スケジュール発表は早めに」という要望もいただいていますが、
すみません、もう少々お待ちください。

また、スポンサーについても、現在、いくつかの企業様から
お申し出をいただいております。
こちらも、近いうちにとりまとめてお知らせできるかと思います。

気がつけば開催まであと2ヶ月です、
イベントの参加申し込みもそろそろ開始できるかと思います。

やきもきされてるかたも多いと思います、ごめんなさい、
急ぎ進めてゆきたいと思っていますので、
よろしくお願いします(/･ω･)/



-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[Talk-it] proposta introduzione cai_scale

[Alfredo Gattai]

Ciao,

mi riallaccio ad un thread partito da Marco Barbieri riguardo
l'introduzione della scala di difficolta' dei sentieri in uso al CAI.
Praticamente direi che i vari argomenti sono stati sviscerati tutti e ad
occhio mi pare che non ci sia una particolare opposizione ad introdurlo
ovviamente con tutti i pro ed i contro relativi.

In quanto membro attivo di una commisione sentieri del CAI (La
Spezia-Liguria) nonche' mappatore OSM e grande sostenitore del bisogno del
CAI di contribuire attivamente alla mappatura di sentieri e rifugi in OSM,
volevo dare il mio contributo.

Per cominciare sono andato avanti con la proposal page

http://wiki.openstreetmap.org/wiki/Proposal_process/cai_scale

E' in draft, vi sarei grato se la visitaste, commentaste e correggeste cio'
che ritenete opportuno prima che vada avanti con la procedura.

Riassumerei il tutto cosi:

- sac_scale per quanto intuitivo e molto diffuso non e' paragonabile alla
scala italiana in maniera facile e non comprenderebbe alcuni dei casi
nostrani

- cai_scale non deve sostituire sac_scale ma semmai e' complementare in
aggiunta per l'utente medio italiano che lo troverebbe di piu' facile
lettura oltre che a corrispondere alle indicazioni sui segnali e sulle mappe

- che la sua introduzione possa facilitare l'avvicinamento del CAI e'
innegabile, difatto le domande che mi vengono fatte piu' spesso riguardano
proprio le localizzazioni

- l'eventuale lavoro in piu' e' trascurabile per vari motivi, intanto fa
parte di quello che normalmente fa un mappatore, poi riuscendo a spingere
il CAI e la varie sezioni sempre piu' impegnate a fare rilevi con il GPS
verso il mondo OSM, lo farebbe di fatto "forza fresca"

- il cai_scale da riportare dovrebbe essere non tanto frutto di una
valutazione personale, ma derivante dalla lettura di cio' che e' riportato
sul cartello e dalle conoscenze delle sezioni locali.

- queste informazioni non hanno veramente IP, perche' chiunque mappando
puo' riportare la difficolta' riportata su di un cartello, inoltre quello
che si sta facendo internamente al CAI e' proprio dissipare possibili
antiche paure sul "dar via" dei dati che di fatto dovrebbe essere di tutti.

- personalmente preferirei assegnarlo alla singola way (come per sac_scale)
perche' all'interno di un itinerario, specialmente se turistico ci possono
essere vari tratti asfaltati e/o su mulattiere per le quali non avrebbe
neanche senso assegnarlo. Invece sui singoli tratti ha molto senso perche'
si puo' decidere di percorrere pezzi di questo o quel sentiero e fare degli
anelli di difficolta' bassa invece di percorrerne uno intero che ha tratti
piu' difficili. La difficolta' piu' alta dell' intera relation puo' essere
ricavata dalla way piu' difficile o al limiti per chi vuole non lasciare
nulla al caso, al limite la riporta anche sulla relation.

Ultimo, date un'occhiata ad un inizio di localizzazione fatta da su
waymarkedtrails facendogli modificare leggermente le bandierine di
osmc:symbol

http://hiking.waymarkedtrails.org/#?map=16!44.0761!9.8219

La gentilissima Sara Hoffman l'ha realizzato una volta visti gli esempi di
bandierine CAI che gli ho mandato e vista la massa critica di relazioni che
abbiamo inserito in questa zona. Piano piano magari riusciremo ad
introdurre anche un rendering con la scala di difficolta'.

Ciao e grazie anticipatamente per qualunque contributo voglate dare alla
proposal page

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

[OSM-talk-fr] [OverpassTurbo] Obtenir une seule route à partir de ways?

[Shohreh]

Bonjour

Je voudrais récupérer toutes les
[url=https://www.openstreetmap.org/relation/6278639]"Cycle
Superhighways"[/url] qui existent actuellement à Londres.

Quand j'utilise la requête suivante* dans OverpassTurbo, j'obtiens des
routes qui ne sont en fait que l'assemblage de ways, ce qui fait que lorsque
j'importe les données dans par exemple RidewithGPS, il importe plein de
petits morceaux au lieu d'une seule route:

http://postimg.org/image/9ajclf1jf/

Les données retournées par OverpassTurbo ne sont qu'une longue série de
segments comme celui-ci:
-0.2626814,51.5194257
-0.262647,51.5194477
-0.2627257,51.5195352way/264394139[object
Object]

Que faire pour agréger toutes les ways en un seul morceau?

Merci pour toute aide.

* Voici la requête OT que j'ai utilisée:
/*
This has been generated by the overpass-turbo wizard.
The original search was:
“cycle_network="UK:London Cycle Superhighways"”
*/
[out:json][timeout:25];
// gather results
(
  // query part for: “cycle_network="UK:London Cycle Superhighways"”
  //node["cycle_network"="UK:London Cycle Superhighways"]({{bbox}});
  //way["cycle_network"="UK:London Cycle Superhighways"]({{bbox}});
  relation["cycle_network"="UK:London Cycle Superhighways"]({{bbox}});
);
// print results
out body;
>;
out skel qt;



--
View this message in context: 
http://gis.19327.n5.nabble.com/OverpassTurbo-Obtenir-une-seule-route-a-partir-de-ways-tp5874852.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] Bus e transiti

[girarsi_liste]

Il 06/06/2016 13:28, Cascafico Giovanni ha scritto:
> Ho visto il bel lavoro fatto per Lecce all'opera su travic [1]
> 
> L'utente Gabriele Dri ha appena completato la rete urbana di Udine e
> sarebbe bello vederla su questo client dei transiti.
> 
> Come é stato costruito ed integrato il feed?
> 
> [1]bit.ly / bus-lecce
> 
> 
> --

Io me ne intendo poco o nulla, però ho visto che cliccando su "about" e
poi sulla parola "master thesis", ti scarica un PDF dove viene spiegato
il progetto che è/era una tesi.



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



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

Re: [Talk-cz] OSMHicheck nevidí fotografie rozcestníků

[Zdeněk Pražák]

děkuji 

-- Původní zpráva --
Od: Tom Ka 
Komu: OpenStreetMap Czech Republic 
Datum: 6. 6. 2016 15:45:37
Předmět: Re: [Talk-cz] OSMHicheck nevidí fotografie rozcestníků

"Byla chyba u walleho v DB fotek rozcesntiku, uz je opraveno a funguje.

Bye

Dne 6. června 2016 9:11 Zdeněk Pražák  napsal(a):
> OSMhicheck nevidí fotografie rozcestníků - udává nulové počty
> Pražák
>
> ___
> 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: [Talk-cu] comunidad OSM en Cuba!

[Laura Barroso Pérez]

Ok, me dicen que por aquí www.cubava.cu  

 

 

De: Laura Barroso Pérez [mailto:laura.barr...@hab.desoft.cu] 
Enviado el: Monday, June 6, 2016 9:09 AM
Para: 'OpenStreetMap Cuba'
Asunto: Re: [Talk-cu] comunidad OSM en Cuba!

 

No está mala la idea…creo que la gente de joven club tenían un sitio donde se 
podían hospedar blogs cubanos? Ni idea…si alguien sabe bien del tema…lo 
ideal (y sigo insistiendo con lo mismo) es que el blog sea .cu 

 

De: Hédel Nuñez Bolívar [mailto:he...@hedmon.com] 
Enviado el: Saturday, June 4, 2016 10:26 AM
Para: OpenStreetMap Cuba
Asunto: Re: [Talk-cu] comunidad OSM en Cuba!

 

jeje, gracias por el correo Guillermo. Mis blogs son http://blog.hedmon.com/ y 
http://www.checolatin.com/ pero no tienen que ver mucho con el tema, quizás un 
poco el primero que lo uso más para cosas 'técnicas'. Por eso creo que podamos 
crear un blog específico para el grupo, si es que se van a generar contentidos. 
Los miembros pudieran inscribirse para recibir newsletters y así pudieran 
recibir los posts en el correo, que creen?




Regards,

 

Ing. Hédel Nuñez Bolívar

http://www.hedmon.com

he...@hedmon.com  



 

2016-06-03 14:35 GMT+02:00 Guillermo López  >:

Hola Hedel.
Gracias por el apoyo. En algun momento podriamos necesitar alguna
ayuda "del exterior". jaja. No, serio. Comparte el enlace para tus
blogs y sigue editando siempre que puedas.

Un saludo

El 2/6/16, Hédel Nuñez Bolívar  > 
escribió:

> Hola a todos,
> Me alegra mucho ver que la comunidad en Cuba se impulsa. Lamentablemente
> vivo en el exterior y me resulta imposible participar en los mapatones de la
> isla, aunque desde la distancia una de las vías que exploto para no sentirme
> lejos es editar en OSM, sobre todo Habana del Este.
> Tengo un par de blogs, en los cuales la verdad, no escribo mucho, pero si la
> comunidad se compromete a generar contenidos, yo me comprometo a crear y
> gestionar uno si es necesario.
>
> Si en algo más puedo ayudar me dicen.
>
> Sds
>
> Hédel
>
>> On 01 Jun 2016, at 17:02, Laura Barroso >  > wrote:
>>
>> Hola gente, ayer en la noche Pb y yo nos reunimos, el objetivo de la
>> reunión: cómo organizar la comunidad osm en Cuba, y crear mecanismos para
>> hacer mapatones en la ciudad.
>>
>> El asunto fundamental es que no tenemos mucha divulgación, la gente no
>> sabe qué es OpenStreetMap. Algunas ideas que pensamos implementar:
>>
>> 1. Reunirnos una vez al mes como comunidad.
>> 2. Buscar un espacio para mapear en papel(Alguien conoce algún dueño de un
>> bar o algo parecido??)
>> 3. Llegar a la gente de joven club(respecto a este punto ayer contacté con
>> Rubén el antiguo jefe de movilidad de Desoft, para que nos facilitace el
>> contacto con gente del palacio central)
>> 4. Llegar a las secundarias y preuniversitarios(tal vez crear espacios
>> para charlas?)
>> 5. Hacer un video para el paquete para los mapatones(Ahora mismo el
>> paquete constituye una fuente de distribución masiva a nivel nacional)
>> 6. Contactar con blogueros que tengan que ver con tecnología(ya contamos
>> con el apoyo de Jorge de cubava, su blog http://jorgen.cubava.cu/)
>>
>> La semana próxima nos reuniremos nuevamente para tratar el tema del guión
>> para el video, divulgaré la cita por esta misma vía por si alguien quiere
>> unirse...
>> La discusión está abierta, si alguien tiene alguna idea o algo que aportar
>> adelante!
>>
>>
>>
>>
>>
>> ___
>> Talk-cu mailing list
>> Talk-cu@openstreetmap.org  
>> https://lists.openstreetmap.org/listinfo/talk-cu
>
> ___
> Talk-cu mailing list
> Talk-cu@openstreetmap.org  
> https://lists.openstreetmap.org/listinfo/talk-cu
>

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

 



__ Informacie ESET NOD32 Antivirus, versie la base de firmas de virus 
13079 (20160224) __

ESET NOD32 Antivirus ha comprobado este mensaje.

http://www.eset.com

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

Re: [Talk-cz] OSMHicheck nevidí fotografie rozcestníků

[Tom Ka]

Byla chyba u walleho v DB fotek rozcesntiku, uz je opraveno a funguje.

Bye

Dne 6. června 2016 9:11 Zdeněk Pražák  napsal(a):
> OSMhicheck nevidí fotografie rozcestníků - udává nulové počty
> Pražák
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>

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

Re: [Talk-in] Railway station GPS co-ordinates

[Shibu Narayanan]

Hi,

My email with an attachment has not been approved because of the large size.

I have uploaded it to this location 
https://raw.githubusercontent.com/tnshibu/osm_data_extract/master/data/india_railway_station_list.txt

You can find the GPS co-ordinates of railways stations in India.  The “ref” 
refers to the Indian railway station code, I think.

The data extracted is for nodes which have the tags with key=”railway” and 
value=”station”.

The extracted data is pipe(‘|’) delimited.

If anyone requires similar data for other tags, let me know, I will try to 
extract them and give you.

Hope someone finds this useful.

 

Sutripta,

All data entered in OSM is ground validated I would assume.  Because it is 
entered individually by contributors, my assumption is that a person familiar 
with the place is the one who is entering the data to OSM.

 

 

Shibu Narayanan 
Oracle Financial Services | Bangalore | India
Office:0091-80-4918-1692 | Mobile:0091-99800-64282

 

From: Sutripta [mailto:sutri...@gmail.com] 
Sent: Tuesday, May 17, 2016 11:23 AM
To: OpenStreetMap in India
Subject: Re: [Talk-in] Railway station GPS co-ordinates

 

Hi, 

Thanks. 

How does one know if an object has been groundtruthed/ validated? 

 

Regards 

Sutripta 

 

On 16 May 2016 at 13:17, Shibu Narayanan mailto:shibu.naraya...@oracle.com; \nshibu.naraya...@oracle.com> wrote:

The link suggested by Arun http://download.geofabrik.de/asia/india.html has a 
10GB xml file which contains the required information.

I will extract it as a csv and post the results here.  

 

Shibu Narayanan 
Oracle Financial Services | Bangalore | India
Office:0091-80-4918-1692 | Mobile:0091-99800-64282

 

From: Sutripta (Gmail) [mailto:HYPERLINK "mailto:sutri...@gmail.com; 
\nsutri...@gmail.com] 
Sent: Monday, May 16, 2016 12:10 PM
To: OpenStreetMap in India
Subject: Re: [Talk-in] Railway station GPS co-ordinates

 

Hi, 
Is the list of Railway Stations/ Junctions in India available as a CSV/ Excel 
file? Maybe with a column saying 'Ground truthed/ validated'. 

Sometime back there was a XML file from IR, but as pointed out by Arun Ganesh, 
had a lot of errors. 

Regards 
Sutripta 

On 12-05-2016 22:19, Arun Ganesh wrote:

Hey Shibu, you can extract it live from OSM using overpass: 
http://overpass-turbo.eu/s/gbk 

 

If you want a shapefile of a larger area, suggest you download the OSM extract 
from geofabrik http://download.geofabrik.de/asia/india.html

 

The POI layer should have the railway stations.

 

On Thu, May 12, 2016 at 9:59 PM, Shibu Narayanan mailto:shibu.naraya...@oracle.com; \nshibu.naraya...@oracle.com> wrote:

Hi,

How do I get the list of all railway stations in Karnataka(or any other state) 
and also its GPS co-ordinates?

 

Shibu Narayanan 
Oracle Financial Services | Bangalore | India
Office:HYPERLINK "tel:0091-80-4918-1692" \n0091-80-4918-1692 | Mobile:HYPERLINK 
"tel:0091-99800-64282" \n0091-99800-64282

 


___
Talk-in mailing list
HYPERLINK "mailto:Talk-in@openstreetmap.org; \ntalk...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in





 

-- 

Arun Ganesh

@planemad

 

___
Talk-in mailing list
HYPERLINK "mailto:Talk-in@openstreetmap.org; \ntalk...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

 


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

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

[Talk-GB] OS open map local polygon accuracy

[roger]

Hi,
I have been looking at the OS openmap local vector dataset. I noticed that the coordinates in there are centimetre level accuracy. I am speculating how the OS made this dataset a "nominal viewing scale" of  1:1. Scales are somewhat irrelevant to vector data. Have they degraded the geometry points by thinning or averaging, or is the data still at survey level accuracy? I have some old (paid for) OS master map data. It would be interesting to compare the polygons in there with the the openmap local ones. But before I search my loft for the disc, has anyone already done this?
Roger
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[FR]

Le 06/06/2016 10:50, g...@laposte.net a écrit :

Autre remarque, je trouve regrettable de noter en source [année de
reference = 2016] après la mention "IGN France" alors que les photos
datent parfois de plusieurs années. (mais je ne vois pas comment
retrouver  l’année vraie des photos)


Bonjour
Osmose n'aime pas "source=BDOrtho IGN 2016"
message d'erreur "tag source illégal ou incomplet"
FR


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

Re: [Talk-cz] Chybne rozcestniky

[Tom Ka]

Wallemy se to bud rozbilo nebo to nejak predelal, takze OsmHiCheck pro
rozcestniky nema z ceho brat data.

Dne 5. června 2016 23:30 Tomas Novotny  napsal(a):
> Ahoj,
>
> jestli myslis BO357, tak ten jsem nahraval v dobe (tyden zpet?), kdy pry na
> serveru doslo misto, takze zaznam tam sice je, ale fotka se ztratila. To
> stejne BO362. Nebo je to tim, ze nejedou rozcestniky na OsmHiCheck, jak
> psal Tomas dopoledne?
> Ty spatne fotky nejak nahraji znova.
>
> Stoupa
>
> On Sun, 5 Jun 2016 20:59:06 +0200
> Miroslav Suchý  wrote:
>
>> Tome,
>> koukam na osmcz ze je docela dost rozcestniku oznaceno chybne a pritom
>> mi prijdou ze jsou OK.
>> Namatkou, proc napr
>>http://openstreetmap.cz/#map=18/49.21050/16.41143=GB
>> je oznacen jako chybny? Fotka tam je. Je umistnena cca 5 metru daleko,
>> takze by se to melo sparovat, ne?
>>
>> Mirek
>>
>> ___
>> 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: [Talk-de] zur Info: Bicycle=yes/designated als Anzeige Benutzungspflicht aufgeben

[Joerg Fischer]

Martin Koppenhoefer wrote:

> Stimmt nicht, Joachim hat das doch vor 6 Tagen beantwortet, und ja, es gibt
> diese Anwendung, es ist sogar die Standardanwendung (OSM Karte).

Lies doch mal die Threads in denen Du schreibst vollständig.

Jörg

-- 
There are only 10 types of people in the world:
Those who understand binary, and those who don't...


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

[Talk-it] Bus e transiti

[Cascafico Giovanni]

Ho visto il bel lavoro fatto per Lecce all'opera su travic [1]

L'utente Gabriele Dri ha appena completato la rete urbana di Udine e
sarebbe bello vederla su questo client dei transiti.

Come é stato costruito ed integrato il feed?

[1]bit.ly / bus-lecce


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

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Eric Sibert]

Voilà, j'ai mis en place un proxy pour tester l'accès à la BD Ortho suite à
la signature de la convention avec l'IGN vendredi


C'est une très bonne nouvelle alors qu'à une époque, on parlait de  
refaire nous même l'orthorectification...



Merci de remonter les problèmes que vous rencontrerez


Tout va bien. J'ai l'impression qu'en montagne, le calage est meilleur  
qu'avec Bing.


Eric



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

Re: [Talk-at] Name-Tag: TEDi vs Tedi

[Robin Däneke]

Hallo noch einmal,
Unglaublich, auf wie viele Arten man Tedi und T€di schreiben kann... Es gab 
echt mindestens 5 verschiedene Schreibweisen in Ö & DE... Es ist wohl als 
normaler "Name"-Tag TEDi das richtige... Danke für die Hilfe.
Mit freundlichen GrüßenRobinD ___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[Christian Quest]

Le 06/06/2016 à 12:30, Nicolas Dumoulin a écrit :

Salut,

Le Fri, 3 Jun 2016 19:28:51 +0200,
François Lacombe  a écrit :

Quid de proposer au DWG de faire une migration en masse ?
Plutôt facile à réaliser : overpass => query sur operator=ERDF => JSOM
ctrl+A => operator=Enedis => Upload

Le principal enjeu est l'information de la communauté et la mise à
jour des scripts de consommation.

Le cas se présente régulièrement : comment gérer le renommage en masse
sans casser les dépendances des outils aux noms dans la base OSM.
Et là, suite à la fantastique présentation de wikidata à Clermont, je
me dis et je vous transmets :
Si on mettais operator=wikidata:Q3587594 plutôt que Enedis ?
https://www.wikidata.org/wiki/Q3587594

Ça implique aux outils de représentation d'utiliser wikidata, et je
suis d'accord ça alourdi un peu le processus.
Mais sinon, ça simplifierai beaucoup de chose :-)

C'est dans la même veine que l'idée de Jean-Louis lors de sa
présentation : déplacer dans wikidata les histoires de liste de noms
alternatifs à rallonge. Wikidata est conçu pour ça, et on est vite
limité dans OSM avec nos quelques variantes de *_name et name_*.

C'est pas évident à mettre en place, mais je trouve cela très séduisant.



C'est très machine friendly mais par du tout human friendly... et pour 
l'instant les contributeurs sont plus des humain que des machines ;)


Ce qui pose plus problème c'est plutôt les clés que les valeurs... 
ref:RFF=* à remplacer à terme par ref:SNCF=* ?


--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Christian Quest]

Le 06/06/2016 à 11:41, Romain MEHUT a écrit :
Le 6 juin 2016 à 10:50, > a 
écrit :


Juste pour info :

Vous aurez remarqué que pour les zooms 6 à 12 l'ensemble de la
planète est mise a disposition !
Pour les zones désertiques ou reculée cela peut être utile.

Autre remarque, je trouve regrettable de noter en source [année de
reference = 2016] après la mention "IGN France" alors que les
photos datent parfois de plusieurs années.


+ 1 pour juste écrire "BDOrtho IGN"


Le millésime est en effet explicitement conservé dans les métadonnées du 
changeset ;)



(mais je ne vois pas comment retrouver  l’année vraie des photos)


Les années sont indiquées ici : 
https://gist.github.com/cquest/e0682246cce5dc562f8f1b3135466b4b


Attention, sur les derniers niveaux de zooms (19) on a parfois une 
version plus ancienne à certains endroits.
Dans ce cas, dans JOSM, je désactive "zoom auto" avec un clic droit sur 
le fond.


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[Nicolas Dumoulin]

Salut,

Le Fri, 3 Jun 2016 19:28:51 +0200,
François Lacombe  a écrit :
> Quid de proposer au DWG de faire une migration en masse ?
> Plutôt facile à réaliser : overpass => query sur operator=ERDF => JSOM
> ctrl+A => operator=Enedis => Upload
> 
> Le principal enjeu est l'information de la communauté et la mise à
> jour des scripts de consommation.

Le cas se présente régulièrement : comment gérer le renommage en masse
sans casser les dépendances des outils aux noms dans la base OSM.
Et là, suite à la fantastique présentation de wikidata à Clermont, je
me dis et je vous transmets :
Si on mettais operator=wikidata:Q3587594 plutôt que Enedis ?
https://www.wikidata.org/wiki/Q3587594

Ça implique aux outils de représentation d'utiliser wikidata, et je
suis d'accord ça alourdi un peu le processus.
Mais sinon, ça simplifierai beaucoup de chose :-)

C'est dans la même veine que l'idée de Jean-Louis lors de sa
présentation : déplacer dans wikidata les histoires de liste de noms
alternatifs à rallonge. Wikidata est conçu pour ça, et on est vite
limité dans OSM avec nos quelques variantes de *_name et name_*.

C'est pas évident à mettre en place, mais je trouve cela très séduisant.

-- 
Nicolas Dumoulin


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

Re: [Talk-de] zur Info: Bicycle=yes/designated als Anzeige Benutzungspflicht aufgeben

[Martin Koppenhoefer]

Am 5. Juni 2016 um 08:55 schrieb Joerg Fischer :

> Das ist nicht das primäre Problem. Auf meine Frage ob es denn irgendeine
> Anwendung gibt die das dann als blauen Radweg zeigt kam keine Antwort.
>


Stimmt nicht, Joachim hat das doch vor 6 Tagen beantwortet, und ja, es gibt
diese Anwendung, es ist sogar die Standardanwendung (OSM Karte).

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

Re: [OSM-talk-fr] ERDF et autres Acronymes prise en comptes des noms longs

[Jérôme Seigneuret]

Ducoup on ne mettrait que les "marques" déposés à Institut national de la
propriété industrielle (INPI) ou/et celle au *Trademark Clearinghouse
(TMCH)*

Le trademark ne sert qu'a protéger un nom et c'est pas forcément nécessaire
si ce nom ne sert pas à vendre des produits ...

C'est loin d'être fiable pour isolé une compagnie à moins d'avoir la portée
géographique de ce nom. Il y a deux CNR par exemple enregistrées au TMCH


A moins de mettre aussi le numéro d'enregistrement...

Le 6 juin 2016 à 11:09, Francescu GAROBY  a écrit :

> > La question est plutôt: Doit-on uniformiser la manière de saisir de ce
> genre d'information pour l'ensemble des acronymes (public ou EPIC) comme
> pour le CNRS, SNCF, ERDF, CNR et autres?  Il n'y a pas de short_operator
> comme le short_name
> > Et normalement les abréviations sont à proscrire.
>
> Oui, mais ces acronymes sont souvent des marques déposées (c'est au moins
> le cas pour SNCF). Du coup, les utiliser comme valeur pour operator ou
> brand (plutôt que de créer un short_operator qui ne sera pas utilisé, ou
> qui fera doublon) serait logique, non ?
>
>
> Francescu
>
> Le 6 juin 2016 à 11:02, Jérôme Seigneuret  a
> écrit :
>
>> Bonjour,
>>
>> Bonjour,
>>>
>>> Il s'agit également de prendre en compte le libellé "Électricité Réseau
>>> Distribution France" que j'ai écrit tel quel car vu ainsi sur le terrain...
>>>
>>
>> J'ai créé un autre sujet pour cette partie car c'est une autre
>> problématique.
>>
>> La prise en compte, je dirais que c'est pas le problème. Autant le nom
>> c'est plus polémique mais les tag *operator* et *brand* je pense qu'on
>> peut uniformiser sans avoir à faire du zèle (s'il y a une faute
>> d'orthographe on va pas la mettre dans la base mais signaler le problème
>> comme pour les noms de rue)
>>
>> La question est plutôt: Doit-on uniformiser la manière de saisir de ce
>> genre d'information pour l'ensemble des acronymes (public ou EPIC) comme
>> pour le CNRS, SNCF, ERDF, CNR et autres?  Il n'y a pas de short_operator
>> comme le short_name
>> Et normalement les abréviations sont à proscrire.
>>
>>
>> Le problème des noms complets, c'est la recherche usuelle. Je ne sais pas
>> pour vous, mais j'utilise ERDF ou SNCF et non Électricité Réseau
>> Distribution France ou Société National des Chemins de fer Français
>>
>> Le problème des acronymes, c'est de ce retrouver dans une zone
>> géographique et un même domaine d'application à avoir le même *operator*
>>
>>
>> Il y a aussi l'ensemble des statuts suivant quand ils sont présents dans
>> l'affichage...
>>
>>- EARL : Entreprise agricole à responsabilité limitée
>>- EI : Entreprise individuelle
>>- EIRL : Entreprise individuelle à responsabilité limitée (01.01.2010)
>>- EURL : Entreprise unipersonnelle à responsabilité limitée
>>- GAEC : Groupement agricole d'exploitation en commun
>>- GEIE : Groupement européen d'intérêt économique
>>- GIE : Groupement d'intérêt économique
>>- SARL : Société à responsabilité limitée
>>- SA : Société anonyme
>>- SAS : Société par actions simplifiée
>>- SASU : Société par actions simplifiée unipersonnelle
>>- SC : Société civile
>>- SCA : Société en commandite par actions
>>- SCI : Société civile immobilière
>>- SCIC : Société coopérative d'intérêt collectif
>>- SCM : Société civile de moyens
>>- SCOP : Société coopérative ouvrière de production
>>- SCP : Société civile professionnelle
>>- SCS : Société en commandite simple
>>- SEL : Société d'exercice libéral
>>- SELAFA : Société d'exercice libéral à forme anonyme
>>- SELARL : Société d'exercice libéral à responsabilité limitée
>>- SELAS : Société d'exercice libéral par actions simplifiée
>>- SELCA : Société d'exercice libéral en commandite par actions
>>- SEM : Société d'économie mixte
>>- SEML : Société d'économie mixte locale
>>- SEP : Société en participation
>>- SICA : Société d'intérêt collectif agricole
>>- SNC : Société en nom collectif
>>
>>
>> J'ai pas de solution préconçu mais un choix doit être fait sur la manière
>> de saisir et il faudra essayer de s'y tenir pour pouvoir exploiter les
>> données correctement.
>>
>> Bonne journée,
>> Jérôme
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Francescu
>
> ___
> 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] Test accès BD Ortho depuis JOSM...

[Romain MEHUT]

Le 6 juin 2016 à 10:50,  a écrit :

> Juste pour info :
>
> Vous aurez remarqué que pour les zooms 6 à 12 l'ensemble de la planète est
> mise a disposition !
> Pour les zones désertiques ou reculée cela peut être utile.
>
> Autre remarque, je trouve regrettable de noter en source [année de
> reference = 2016] après la mention "IGN France" alors que les photos datent
> parfois de plusieurs années.
>

+ 1 pour juste écrire "BDOrtho IGN"


> (mais je ne vois pas comment retrouver  l’année vraie des photos)
>

Les années sont indiquées ici :
https://gist.github.com/cquest/e0682246cce5dc562f8f1b3135466b4b

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

Re: [OSM-talk-fr] ERDF et autres Acronymes prise en comptes des noms longs

[Francescu GAROBY]

> La question est plutôt: Doit-on uniformiser la manière de saisir de ce
genre d'information pour l'ensemble des acronymes (public ou EPIC) comme
pour le CNRS, SNCF, ERDF, CNR et autres?  Il n'y a pas de short_operator
comme le short_name
> Et normalement les abréviations sont à proscrire.

Oui, mais ces acronymes sont souvent des marques déposées (c'est au moins
le cas pour SNCF). Du coup, les utiliser comme valeur pour operator ou
brand (plutôt que de créer un short_operator qui ne sera pas utilisé, ou
qui fera doublon) serait logique, non ?


Francescu

Le 6 juin 2016 à 11:02, Jérôme Seigneuret  a
écrit :

> Bonjour,
>
> Bonjour,
>>
>> Il s'agit également de prendre en compte le libellé "Électricité Réseau
>> Distribution France" que j'ai écrit tel quel car vu ainsi sur le terrain...
>>
>
> J'ai créé un autre sujet pour cette partie car c'est une autre
> problématique.
>
> La prise en compte, je dirais que c'est pas le problème. Autant le nom
> c'est plus polémique mais les tag *operator* et *brand* je pense qu'on
> peut uniformiser sans avoir à faire du zèle (s'il y a une faute
> d'orthographe on va pas la mettre dans la base mais signaler le problème
> comme pour les noms de rue)
>
> La question est plutôt: Doit-on uniformiser la manière de saisir de ce
> genre d'information pour l'ensemble des acronymes (public ou EPIC) comme
> pour le CNRS, SNCF, ERDF, CNR et autres?  Il n'y a pas de short_operator
> comme le short_name
> Et normalement les abréviations sont à proscrire.
>
>
> Le problème des noms complets, c'est la recherche usuelle. Je ne sais pas
> pour vous, mais j'utilise ERDF ou SNCF et non Électricité Réseau
> Distribution France ou Société National des Chemins de fer Français
>
> Le problème des acronymes, c'est de ce retrouver dans une zone
> géographique et un même domaine d'application à avoir le même *operator*
>
>
> Il y a aussi l'ensemble des statuts suivant quand ils sont présents dans
> l'affichage...
>
>- EARL : Entreprise agricole à responsabilité limitée
>- EI : Entreprise individuelle
>- EIRL : Entreprise individuelle à responsabilité limitée (01.01.2010)
>- EURL : Entreprise unipersonnelle à responsabilité limitée
>- GAEC : Groupement agricole d'exploitation en commun
>- GEIE : Groupement européen d'intérêt économique
>- GIE : Groupement d'intérêt économique
>- SARL : Société à responsabilité limitée
>- SA : Société anonyme
>- SAS : Société par actions simplifiée
>- SASU : Société par actions simplifiée unipersonnelle
>- SC : Société civile
>- SCA : Société en commandite par actions
>- SCI : Société civile immobilière
>- SCIC : Société coopérative d'intérêt collectif
>- SCM : Société civile de moyens
>- SCOP : Société coopérative ouvrière de production
>- SCP : Société civile professionnelle
>- SCS : Société en commandite simple
>- SEL : Société d'exercice libéral
>- SELAFA : Société d'exercice libéral à forme anonyme
>- SELARL : Société d'exercice libéral à responsabilité limitée
>- SELAS : Société d'exercice libéral par actions simplifiée
>- SELCA : Société d'exercice libéral en commandite par actions
>- SEM : Société d'économie mixte
>- SEML : Société d'économie mixte locale
>- SEP : Société en participation
>- SICA : Société d'intérêt collectif agricole
>- SNC : Société en nom collectif
>
>
> J'ai pas de solution préconçu mais un choix doit être fait sur la manière
> de saisir et il faudra essayer de s'y tenir pour pouvoir exploiter les
> données correctement.
>
> Bonne journée,
> Jérôme
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

[OSM-talk-fr] ERDF et autres Acronymes prise en comptes des noms longs

[Jérôme Seigneuret]

Bonjour,

Bonjour,
>
> Il s'agit également de prendre en compte le libellé "Électricité Réseau
> Distribution France" que j'ai écrit tel quel car vu ainsi sur le terrain...
>

J'ai créé un autre sujet pour cette partie car c'est une autre
problématique.

La prise en compte, je dirais que c'est pas le problème. Autant le nom
c'est plus polémique mais les tag *operator* et *brand* je pense qu'on peut
uniformiser sans avoir à faire du zèle (s'il y a une faute d'orthographe on
va pas la mettre dans la base mais signaler le problème comme pour les noms
de rue)

La question est plutôt: Doit-on uniformiser la manière de saisir de ce
genre d'information pour l'ensemble des acronymes (public ou EPIC) comme
pour le CNRS, SNCF, ERDF, CNR et autres?  Il n'y a pas de short_operator
comme le short_name
Et normalement les abréviations sont à proscrire.


Le problème des noms complets, c'est la recherche usuelle. Je ne sais pas
pour vous, mais j'utilise ERDF ou SNCF et non Électricité Réseau
Distribution France ou Société National des Chemins de fer Français

Le problème des acronymes, c'est de ce retrouver dans une zone géographique
et un même domaine d'application à avoir le même *operator*


Il y a aussi l'ensemble des statuts suivant quand ils sont présents dans
l'affichage...

   - EARL : Entreprise agricole à responsabilité limitée
   - EI : Entreprise individuelle
   - EIRL : Entreprise individuelle à responsabilité limitée (01.01.2010)
   - EURL : Entreprise unipersonnelle à responsabilité limitée
   - GAEC : Groupement agricole d'exploitation en commun
   - GEIE : Groupement européen d'intérêt économique
   - GIE : Groupement d'intérêt économique
   - SARL : Société à responsabilité limitée
   - SA : Société anonyme
   - SAS : Société par actions simplifiée
   - SASU : Société par actions simplifiée unipersonnelle
   - SC : Société civile
   - SCA : Société en commandite par actions
   - SCI : Société civile immobilière
   - SCIC : Société coopérative d'intérêt collectif
   - SCM : Société civile de moyens
   - SCOP : Société coopérative ouvrière de production
   - SCP : Société civile professionnelle
   - SCS : Société en commandite simple
   - SEL : Société d'exercice libéral
   - SELAFA : Société d'exercice libéral à forme anonyme
   - SELARL : Société d'exercice libéral à responsabilité limitée
   - SELAS : Société d'exercice libéral par actions simplifiée
   - SELCA : Société d'exercice libéral en commandite par actions
   - SEM : Société d'économie mixte
   - SEML : Société d'économie mixte locale
   - SEP : Société en participation
   - SICA : Société d'intérêt collectif agricole
   - SNC : Société en nom collectif


J'ai pas de solution préconçu mais un choix doit être fait sur la manière
de saisir et il faudra essayer de s'y tenir pour pouvoir exploiter les
données correctement.

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

Re: [Talk-cz] Dalsi preklady wiki

[Dalibor Jelínek]

Cau,

prehled nemame, nevime uplne, jak ho ziskat.

Ale asi bychom to ani vedet nechteli. Je toho hooodne.

 

Dalibor

 

From: Marián Kyral [mailto:mky...@email.cz] 
Sent: Monday, June 6, 2016 10:52 AM
To: OpenStreetMap Czech Republic 
Subject: Re: [Talk-cz] Dalsi preklady wiki

 

Zdar,
díky. Jedete jak pilky. Máte přehled, kolik procent vám ještě chybí? Nebo to 
raději nechcete vědět? :-D

Marián



-- Původní zpráva --
Od: Dalibor Jelínek  >
Komu: 'OpenStreetMap Czech Republic'  >
Datum: 6. 6. 2016 10:49:27
Předmět: [Talk-cz] Dalsi preklady wiki

 

Ahoj, 

ve spolupráci s Lukášem přinášíme další překlady wiki k počtení a případným 
opravám. 

 

Mějte se, 

Dalibor 

 

*   historic  
=locomotive  , 
historic  =manor 
 , historic 
 =memorial 
 , historic 
 =milestone 
 , historic 
 =monastery 
 , historic 
 =pillory 
  - 12.4.2016 
*   historic  =monument 
 , historic 
 =optical_telegraph 
  - 
13.4.2016 
*   historic  
=rune_stone  , 
historic  =ship 
 , historic 
 =tree_shrine 
 , historic 
 =wreck 
 , historic 
 =wayside_cross 
 , historic 
 =wayside_shrine 
  - 
9.5.2016 
*   emergency  
=ambulance_station 
 , 
emergency  =defibrillator 
  - 
11.5.2016 
*   emergency  
=fire_extinguisher 
 , 
emergency  =fire_flapper 
 , 
emergency  =fire_hydrant 
 , , 
emergency  =fire_hose 
 , emergency 
 =water_tank 
 , emergency 
 =lifeguard_base 
 , 
emergency  
=lifeguard_tower 
 , 
emergency  
=lifeguard_platform 
 , 
emergency  
=lifeguard_place 
 , 
emergency  =life_ring 
 , emergency 
 =assembly_point 
 , 
emergency  

Re: [Talk-cz] Dalsi preklady wiki

[Marián Kyral]

Zdar,
díky. Jedete jak pilky. Máte přehled, kolik procent vám ještě chybí? Nebo to
raději nechcete vědět? :-D

Marián



-- Původní zpráva --
Od: Dalibor Jelínek 
Komu: 'OpenStreetMap Czech Republic' 
Datum: 6. 6. 2016 10:49:27
Předmět: [Talk-cz] Dalsi preklady wiki

"


Ahoj, 

ve spolupráci s Lukášem přinášíme další překlady wiki k počtení a případným 
opravám. 

 

Mějte se, 

Dalibor 

 

   *  historic(http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=
   locomotive
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dlocomotive), 
   historic(http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=manor
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dmanor), historic
   (http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=memorial
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dmemorial), historic
   (http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=milestone
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dmilestone), 
   historic(http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=monastery
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dmonastery), 
   historic(http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=pillory
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dpillory) - 12.4.
   2016 
   * historic(http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=monument
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dmonument), historic
   (http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=optical_telegraph
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Doptical_telegraph) 
   - 13.4.2016 
   * historic(http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=rune_stone
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Drune_stone), 
   historic(http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=ship
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dship), historic
   (http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=tree_shrine
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dtree_shrine), 
   historic(http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=wreck
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dwreck), historic
   (http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=wayside_cross
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dwayside_cross), 
   historic(http://wiki.openstreetmap.org/wiki/Cs:Key:historic)=wayside_
   shrine
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:historic%3Dwayside_shrine) - 
   9.5.2016 
   * emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=
   ambulance_station
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dambulance_station)
   , emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=
   defibrillator
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Ddefibrillator) - 
   11.5.2016 
   * emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=fire_
   extinguisher
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dfire_extinguisher)
   , emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=fire_
   flapper
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dfire_flapper), 
   emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=fire_
   hydrant
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dfire_hydrant), , 
   emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=fire_hose
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dfire_hose), 
   emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=water_tank
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dwater_tank), 
   emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=lifeguard_
   base
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dlifeguard_base), 
   emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=lifeguard_
   tower
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dlifeguard_tower), 
   emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=lifeguard_
   platform
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dlifeguard_platform)
   , emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=
   lifeguard_place
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dlifeguard_place), 
   emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=life_ring
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dlife_ring), 
   emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=assembly_
   point
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dassembly_point), 
   emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=access_
   point(http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Daccess_point)
   , emergency(http://wiki.openstreetmap.org/wiki/Cs:Key:emergency)=ses_
   station
   (http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dses_station), 
   

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[gnrc]

Juste pour info : 

Vous aurez remarqué que pour les zooms 6 à 12 l'ensemble de la planète est mise 
a disposition ! 
Pour les zones désertiques ou reculée cela peut être utile. 

Autre remarque, je trouve regrettable de noter en source [année de reference = 
2016] après la mention "IGN France" alors que les photos datent parfois de 
plusieurs années. (mais je ne vois pas comment retrouver l’année vraie des 
photos) 

- Mail original -

De: "Christian Quest"  
À: "Discussions sur OSM en français"  
Envoyé: Vendredi 27 Mai 2016 18:09:44 
Objet:  [OSM-talk-fr] Test accès BD Ortho depuis JOSM... 

Voilà, j'ai mis en place un proxy pour tester l'accès à la BD Ortho suite à la 
signature de la convention avec l'IGN vendredi dernier (déjà une semaine !). 

Afin de respecter les termes de la convention, j'ai installé un proxy sur un de 
nos serveurs, qui assure en plus un peu de cache (8Go conservé maximum 30j). 
J'ai aussi simplifié l'URL car celles du géoportail piquent les yeux ;) 

Donc dans JOSM, vous pouvez ajouter: 
tms[19]: http://proxy-ign.openstreetmap.fr/bdortho/{zoom}/{x}/{y}.jpg 

Rappel: la convention n'autorise qu'un usage pour compléter et mettre à jour 
les données OSM, donc un usage dans nos outils d'édition. 

Pensez à mettre "source=BDOrtho IGN 2016" sur les changeset ou les objets. 

Voici aussi un fichier CSV avec les dates de prises de vue et la résolution par 
département: https://gist.github.com/cquest/e0682246cce5dc562f8f1b3135466b4b 

Sur certains départements, le(s) dernier(s) niveau(x) de zoom peuvent être plus 
anciens que l'année indiquée. C'est le cas sur le 89. 

Merci de remonter les problèmes que vous rencontrerez 
-- 
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-nl] Fwd: 10 juni a.s: Collaborative Mapping in support of UNESCO World Heritage Nominations (in A'dam)

[St Niklaas]

Beste Just,



Bedankt voor de info.



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

[Talk-cz] Dalsi preklady wiki

[Dalibor Jelínek]

Ahoj,

ve spolupráci s Lukášem přinášíme další překlady wiki k počtení a případným
opravám.

 

Mějte se,

Dalibor

 

*   historic 
=locomotive
 , historic
 =manor
 , historic
 =memorial
 , historic
 =milestone
 , historic
 =monastery
 , historic
 =pillory
  - 12.4.2016
*   historic 
=monument  ,
historic 
=optical_telegraph
  -
13.4.2016
*   historic 
=rune_stone
 , historic
 =ship
 , historic
 =tree_shrine
 ,
historic  =wreck
 , historic
 =wayside_cross
 ,
historic 
=wayside_shrine
  -
9.5.2016
*   emergency 
=ambulance_station
 ,
emergency 
=defibrillator
  -
11.5.2016
*   emergency 
=fire_extinguisher
 ,
emergency 
=fire_flapper
 ,
emergency 
=fire_hydrant
 , ,
emergency  =fire_hose
 ,emergency
 =water_tank
 ,
emergency 
=lifeguard_base
 ,
emergency 
=lifeguard_tower
 ,
emergency 
=lifeguard_platform
 ,
emergency 
=lifeguard_place
 ,
emergency  =life_ring
 ,
emergency 
=assembly_point
 ,
emergency 
=access_point
 ,
emergency  =ses_station
 ,
emergency  =siren
 , ref:vatin
 =*, route_master
 =*, outdoor_seating
 =*, min_height
 =*, owner
 =* - 12.5.2016
*   route 

Re: [Talk-cz] Jáma - jak otagovat?

[Marián Kyral]

-- Původní zpráva --
Od: MatějCepl 
Komu: talk-cz@openstreetmap.org
Datum: 6. 6. 2016 0:02:31
Předmět: Re: [Talk-cz] Jáma - jak otagovat?

"On 2016-06-05, 17:53 GMT, Marián Kyral wrote:
>> natural=hole, kdyz je to maly; man_made=embankment kdyz je to 

embankment je nábřeží, ne?
"



Tak  on je to obecně nějaký násep: http://wiki.openstreetmap.org/wiki/Cs:
Key:embankment




Což ovšem nepasuje na díru. To bych musel říct, že celá okolní krajina je 
násep :-D




Marián




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

Re: [OSM-talk-fr] ERDF (et RFF) ont changé de nom

[Romain MEHUT]

Bonjour,

Il s'agit également de prendre en compte le libellé "Électricité Réseau
Distribution France" que j'ai écrit tel quel car vu ainsi sur le terrain...

Romain

Le 3 juin 2016 à 19:28, François Lacombe  a
écrit :

> Bonjour la liste,
>
> comme vous l'avez peut-être vu ces derniers jours, l'opérateur de
> distribution électrique ERDF a changé de nom pour Enedis.
> RFF l'a précédé en 2015 pour donner naissance à SNCF Réseau, pour ne
> citer qu'un cas probablement parmi tant d'autres avec la fusion des
> communes, fusion des régions, etc...
>
> Pourtant dans OSM :
> operator=RFF, 3349 objets
> operator=SNCF Réseau, 3205 objets
> operator=ERDF, 25768 objets
> operator=Enedis, 0 objets
>
> Comme on peut le voir, les objets attribués à RFF migrent
> difficilement vers la nouvelle valeur (si tant est que SNCF Réseau
> soit la valeur à appliquer. La confusion avec Gares & connexion est
> facile et il en va de même avec les autres filiales de la SNCF).
>
> Ça me semble être un problème, et nous avons tout intérêt à avoir un
> ensemble de données cohérentes.
> Il y a un ticket ouvert chez JOSM :
> https://josm.openstreetmap.de/ticket/12914
>
> J'ai déjà commencé à mettre à jour le wiki, mais cela ne suffira
> pourtant pas à obtenir un ensemble cohérent avant un certain nombre
> d'années.
>
> Quid de proposer au DWG de faire une migration en masse ?
> Plutôt facile à réaliser : overpass => query sur operator=ERDF => JSOM
> ctrl+A => operator=Enedis => Upload
>
> Le principal enjeu est l'information de la communauté et la mise à
> jour des scripts de consommation.
>
> A+
>
> François
>
> ___
> 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-be] Import of 2000 DAE in Belgium (Defibrillators / > Défibrillateurs)

[Philippe Casteleyn]

Eindelijk iemand die niet al een wildeman mapt zodra hij gegevens tegenkomt.
Ik heb gisteren een defibrillator tegengekomen in 
Steenokkerzeel.http://www.mapillary.com/map/im/7RmuSqkA2GO9obPesXY8GA/photo

Ik ben vergeten een goede foto te maken.   Mapillary foto's duren immers 12 
seconden om te laden en de kwaliteit is slecht. Dat is wel extra werk.   
Zou zoiets niet in Flickr kunnen getagd worden ? Ik heb eigenlijk zonder ze te 
willen verzamelen al veel defibrillatoren in Mapillary gefotografeerd.In de 
toekomst zullen we Mapillary kunnen trainen om ze te herkennen.
De DAE in het Pachecoinstituut Grootgodshuisstraat 7A, 1000 Brussel  staat 
binnen naast het onthaal en die heb ik dan maar niet gefotografeerd.   Ik had 
geen zin om een hele uitleg te doen. 
Ph Casteleyn 
Dahliastraat 16

2800 Mechelen
animals.slippers.loaders

gsm 0486 516261
Ctrl+v


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

Re: [Talk-it] OSM è una questione di fede?

[nsemboloni]

Non è questione di fede ma di buonsenso, la mappatura descrive la realtà
mentre il rendering la rappresenta graficamente. Se il rendering è
"sbagliato" o poco/troppo dettagliato va corretto quello, non la descrizione
della realtà... 



--
View this message in context: 
http://gis.19327.n5.nabble.com/OSM-e-una-questione-di-fede-tp5874770p5874831.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

[Talk-cz] OSMHicheck nevidí fotografie rozcestníků

[Zdeněk Pražák]

OSMhicheck nevidí fotografie rozcestníků - udává nulové počty
Pražák
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Fotky rozcestniku - nefunguje all/json

[Michal Grézl]

nekomu se povedlo narvat do db neutf znak.
tojson selze a ja to nijak neosetruju:)

opraveno v db.

2016-06-05 8:26 GMT+02:00 Tom Ka :
> OsmHiCheck nejedou rozcestniky, nemam data od wallyho:
>
> The server made a boo boo.
>
> Jestli/jakmile to wally opravi, tak bude funkcni.
>
> Bye
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz



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

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