Re: [Talk-cz] WeeklyOSM CZ 278

2015-12-30 Per discussione Michal Grézl
Vsechny zmeny podlehaji schvaleni, uz ted tam porad kdosi neustale neco maze:).

Ref by se tam mel objevit hned po stisku ok, z neznamych duvodu to zatim nedela.
Po reloadu se objevi napravo, ze atribut byl editovan. Nejspis by se
to tam melo objevit hned.

2015-12-21 14:05 GMT+01:00 Marián Kyral :
> Ahoj,
> Jak vlastně funguje ten editor? Všechny změny podléhají schválení?
>
> Nešlo by tam dát nějakou smysluplnější zprávu? Zkoušel jsem změnu ref a byl
> jsem docela zmaten, že po uložení se "nic" nestalo, ref tam pořád nebyl. Tak
> jsem to zkusil znova, zase nic. Objevil se až později. Možná by nebylo na
> škodu tam dát nějakou zprávu, že na dané položce jsou změny čekající na
> schválení.
>
> Marián
>
> -- Původní zpráva --
> Od: Michal Grézl 
> Komu: OpenStreetMap Czech Republic 
> Datum: 21. 12. 2015 13:42:28
> Předmět: Re: [Talk-cz] WeeklyOSM CZ 278
>
>
> na adrese http://api.openstreetmap.cz/editor-help.html je dokument kde
> je seznam zmen v systemu
> (dnes tam vznikla prvni polozka, pridani poznamek)
>
> a vznika tam navod na pouzivani api atp.
>
> --
> Michal Grézl
> http://openstreetmap.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
>



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

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


Re: [Talk-dk] Copyright

2015-12-30 Per discussione Niels Elgaard Larsen


Tobias Stenby Brixen:
> Hej, jeg har et par spørgsmål i forbindelse med hvordan man finder
> information til brug i OSM.
> 
> Er det ok at:
> 1) tage fx åbningertider fra restauranternes egne hjemmesider, hvor der
> er et copyright symbol på hjemmesiden?
> 2) tage fx åbningertider fra restauranternes egne hjemmesider, hvor der
> ikke er et copyright symbol på hjemmesiden?
> 3) bruge Google søgning (eller anden søgemaskine) til at finde frem til
> en restaurants hjemmeside?

som jeg skrev i en anden mail, så mener jeg at det er ok.

generelt skal man være opmærksom på at det jo ikke kun er dansk
lovgivninger, der er afgørende. Derudover har OSM også deres egne,
formodentligt strengere retningsliner.

> Og til sidst et lidt andet spørgsmål: Er det muligt at søge i talk-dk’s
> arkiver?

Du mener søge i:
https://lists.openstreetmap.org/pipermail/talk-dk/

Mange søgemskiner forstår vist søgninger af typen:
url:https://lists.openstreetmap.org/pipermail/talk-dk/ cykelsti


> På forhånd tak.
> 
> —
> Tobias Stenby Brixen
> 
> 
> 
> 
> 
> 
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
> 

-- 
Niels Elgaard Larsen

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


Re: [Talk-ec] Schotterstraßen

2015-12-30 Per discussione Manfred A. Reiter
Hola Gerhard,

gracias por su contribución.
Esta hecho hoy día. ;-)

Btw: Guten Rutsch
Am 31.12.2015 6:28 vorm. schrieb "Gerhard Benz" :

> Hallo Manfred,
> ich habe einige mit GPS-getrackte Auto-Fahrtrouten von unbekannten Straßen
> in Ecuador aufgezeichnet und als öffentlich an OSM gesendet.
> Dort sind aber nicht als Straßen, sondern nur als Traces sichtbar.
> Könntest du die bitte alle als einfache Schotterstraßen in OSM eintragen?
>
> https://www.openstreetmap.org/edit?gpx=2087406#map=16/-1.8775/-78.5156
> https://www.openstreetmap.org/edit?gpx=2087404#map=16/-1.9289/-78.5433
> https://www.openstreetmap.org/edit?gpx=2039551#map=16/0.1389/-78.2786
> https://www.openstreetmap.org/edit?gpx=2011108#map=16/-6.2771/-78.0531
> (Peru)
> https://www.openstreetmap.org/edit?gpx=2011107#map=16/-6.5419/-77.8698
> (Peru)
>
> Ich wäre dir sehr dafür dankbar.
>
>
> Noch ein gutes erfolgreiches neues Jahr 2016
>
> LG
> Gerhard, CAQ Quito
>
> Am 08.09.2015 um 14:54 schrieb Manfred A. Reiter:
>
>> Buenas,
>>
>> quiero marcar las ubicaciones de las cámaras de esta website
>> http://www.igepn.edu.ec/cotopaxi/camaras-cotopaxi en un mapa:
>>
>>
>> http://umap.openstreetmap.fr/de/map/camaras-cotopaxi_51985#11/-0.6434/-78.4060
>>
>> Las ubicaciones de las cámaras
>> - Barrancas
>> - Callo Donoso
>> - Bocatoma
>> Lamentablemente no puedo determinar.
>>
>> Me gustaría saber donde (aproximadamente) estan situadas las cámaras
>> mencionadas?
>>
>>
>>
>
> ___
> Talk-ec mailing list
> Talk-ec@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ec
>
___
Talk-ec mailing list
Talk-ec@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ec


Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione Tony Emery
La domanialité d'une voie ne doit pas être confondue avec la circulation de
la voie.

Une voie ouverte à la circulation publique peut très bien être dans le
domaine privée d'une commune et donc être contenue dans une parcelle.

L'ordonnance n° 59-115 du 7 janvier 1959 relative à la voirie des
collectivités locales et le décret n°64-262 du 14 mars 1964 relatif aux
caractéristiques techniques, aux alignements, à la conservation et à la
surveillance des voies communales définissent les voies de la manière
suivante :

- Les voies communales (et dépendances) qui font partie du domaine public ;
- Les chemins ruraux qui appartiennent au domaine privé de la commune ;
- Les voies urbaines privées ;
- Les voies privées rurales ;
- Les voies gérées par d'autres collectivités territoriales (Autoroutes,
Départementale,...)

J'ai un pavé de 120 pages qui expliquent tout ça mais après, tldr... 



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Chemin-privative-tp5863525p5863597.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


[Talk-ec] Schotterstraßen

2015-12-30 Per discussione Gerhard Benz

Hallo Manfred,
ich habe einige mit GPS-getrackte Auto-Fahrtrouten von unbekannten 
Straßen in Ecuador aufgezeichnet und als öffentlich an OSM gesendet.

Dort sind aber nicht als Straßen, sondern nur als Traces sichtbar.
Könntest du die bitte alle als einfache Schotterstraßen in OSM eintragen?

https://www.openstreetmap.org/edit?gpx=2087406#map=16/-1.8775/-78.5156
https://www.openstreetmap.org/edit?gpx=2087404#map=16/-1.9289/-78.5433
https://www.openstreetmap.org/edit?gpx=2039551#map=16/0.1389/-78.2786
https://www.openstreetmap.org/edit?gpx=2011108#map=16/-6.2771/-78.0531 
(Peru)
https://www.openstreetmap.org/edit?gpx=2011107#map=16/-6.5419/-77.8698 
(Peru)


Ich wäre dir sehr dafür dankbar.


Noch ein gutes erfolgreiches neues Jahr 2016

LG
Gerhard, CAQ Quito

Am 08.09.2015 um 14:54 schrieb Manfred A. Reiter:

Buenas,

quiero marcar las ubicaciones de las cámaras de esta website
http://www.igepn.edu.ec/cotopaxi/camaras-cotopaxi en un mapa:

http://umap.openstreetmap.fr/de/map/camaras-cotopaxi_51985#11/-0.6434/-78.4060

Las ubicaciones de las cámaras
- Barrancas
- Callo Donoso
- Bocatoma
Lamentablemente no puedo determinar.

Me gustaría saber donde (aproximadamente) estan situadas las cámaras
mencionadas?





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


Re: [OSM-talk-fr] Jointure attributaire dans JOSM

2015-12-30 Per discussione Tony Emery
Jean-Marc Liotier wrote
> Avec ton langage de script préféré: dans le XML Openstreetmap pour
> chaque objet concerné (XMLlib to the rescue !) lit la valeur de
> l'attribut concerné, cherche là dans le jeu de données puis met à jour
> l'attribut souhaité... J'apprends doucement à faire ce genre de choses
> avec Perl - les premières fois ça coute beaucoup de temps mais la courbe
> d'apprentissage est plaisante et c'est autrement plus industrialisable
> qu'une manipulation dans une IHM graphique. 

Il faudra que tu me dises comment tu fais car là, je suis perdu...



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Jointure-attributaire-dans-JOSM-tp5863476p5863600.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


[Talk-in] weeklyOSM 284

2015-12-30 Per discussione Jinal Foflia
The weekly round-up of OSM news, issue # 284 is now available online in
English, giving as always a summary of all things happening in the
OpenStreetMap world:


*http://www.weeklyosm.eu/archives/6538
*


*Highlights of the weeklyOSM*

- Want to increase the speed of editing in JOSM? User baditaflorin has
created a cheat sheet to help us in doing so
*… **-  *Want to know more about "Roads
to Rome" ? Look for the interview with Raphael Reimann …

- Calling all couchmappers at the end of the year: Please click once, sit
back and enjoy the beauty of the world … 
- Mapzen has a Christmas present for all the users …

- Toyota wants to make Google’s mapping tech obsolete …


Enjoy!

weeklyOSM is brought to you by ...
https://wiki.openstreetmap.org/wiki/WeeklyOSM

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


Re: [Talk-GB] Mapping Meet Abbots Bromley 30th Dec

2015-12-30 Per discussione SK53
Many thanks to all who came despite the weather: a very decent turn out of
7 people from 4 Midland counties.

Jerry

On 29 December 2015 at 13:47, SK53  wrote:

> Just a reminder that this meeting is tomorrow. I've added some details on
> the wiki
> 
> .
>
> Meeting times: 10:30 Buttercross, Abbots Bromley
>12:30-12:50 Coach & Horses.
>
> The weather forecast is not promising, wrap up well. I'm afraid it's a bit
> difficult to predict a few weeks in advance with what seems like an endless
> sequence of winter storms coming in.
>
> I'm now going out to enjoy some sunny weather.
>
> Jerry
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-es] Toyota quiere convertir a todos sus coches en mapeadores

2015-12-30 Per discussione Roberto Pla
Una pesadilla que deja pequeño al Gran Hermano. Una cosa es que yo
decida mapear y otra cosa es que las aseguradoras y el fabricante del
coche sigan mis pasos.


> ¿Qué os parece esta noticia?

-- 
Roberto Plà
http://robertopla.net/
Linux user #295179

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


[Talk-it] Mail nuovi utenti

2015-12-30 Per discussione Andrea Lattmann
Ciao a tutti, è da un pò che ci penso e chiedo il vostro aiuto. La mia idea è 
questa: vorrei mandare un messaggio di benvenuto con una breve "guida" con link 
al Wiki di OSM, strumenti e tutto il necessario, pregandoli anche di iscriversi 
in ml, da spedire a tutti i nuovi mappers, visto che giornalmente mi arrivano 
le notifiche dei nuovi iscritti. Questo per creare comunità, evitare import 
senza sapere che bisogna seguire delle regole ecc. Ecc. Idee, proposte, bozze?
Se per voi è una boiata pazzesca lascio stare...

Andrea Lattmann

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


Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione Nicolas Moyroud

Le 30/12/2015 18:20, f.dos.san...@free.fr a écrit :

Pour moi pas de doute si c'est marqué chemin privé -> access=private.
J'utilise access=destination pour les cas "sens interdit sauf riverains".
Moui sauf que quand c'est marqué "rue privée" tu fais quoi ? Des fois ça 
veut dire que c'est une rue qui n'est pas gérée par la collectivité 
locale, mais pas du tout que l'accès est privé. C'est le cas de la rue 
qui mène à mon lieu de travail elle est ouverte au public et elle 
dessert une bien belle brochette de lieux différents (labos de 
recherche, base de canoé-kayak, ...)


Nicolas

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


[OSRM-talk] MPH on OSRM?

2015-12-30 Per discussione Jack Burke
Out of curiosity, are there any plans to bring mph back to the OSRM web
interface?  MPH used to be an option until the last major revision of the
website

--jack "don't judge until you've walked 1.6 km in my shoes"
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk


Re: [Talk-GB] NLS OS 6in E in Potlatch & iD

2015-12-30 Per discussione Steve Doerr

On 30/12/2015 18:31, Tom Hughes wrote:

On 30/12/15 18:26, Steve Doerr wrote:

On 30/12/2015 18:09, Tom Hughes wrote:

On 30/12/15 17:04, Steve Doerr wrote:

On 03/01/2015 17:47, Tom Hughes wrote:


They changed the URL for that layer recently when they merged the
separate England+Wales and Scotland layers for the 2nd edition 6 inch
maps into one layer. I've updated the wiki, but this should work:

tms:http://nls-{switch:0,1,2,3}.tileserver.com/os_6_inch_gb/{zoom}/{x}/{y}.jpg 






Changed again?


Yes, it's now behind an API key because that is one of the layers they
are now selling access to:

http://maps.nls.uk/projects/subscription-api/



OK. Well, this worked for me:
http://nls-0.tileserver.com/fpsUZbxtgtkn/{zoom}/{x}/{y}.jpg


Yes I knew the API key they were using on their own site, but I wasn't 
going to broadcast it to everybody given it is clearly their intent 
that people wanting a key should cough up


Oops!

--
Steve

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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


Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione Jérôme Seigneuret
pareil

Le 30 décembre 2015 à 18:20,  a écrit :

> Pour moi pas de doute si c'est marqué chemin privé -> access=private.
> J'utilise access=destination pour les cas "sens interdit sauf riverains".
>
> - Mail original -
> De: "Jean-Claude Repetto" 
> À: talk-fr@openstreetmap.org
> Envoyé: Mercredi 30 Décembre 2015 17:33:51
> Objet: Re: [OSM-talk-fr] Chemin privative
>
> Bonjour,
>
> Le 30/12/2015 16:37, f.dos.san...@free.fr a écrit :
> >
> > Route à accès privé tag à ajouter : access=private
> > Et noeud (sur la route) à la position où est présente la grille :
> barrier=gate
> >
>
>
> A propos, une voie d'accès à un lotissement, marquée "chemin privé",
> mais sans barrière, doit-elle être étiquetée en
> access=private
> ou
> access=destination ?
>
> Jean-Claude
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione JB
Et parce que j'ai toujours l'esprit tordu, j'en profite pour superposer 
la couche cadastre pour voir si c'est encore un local qui s'est 
approprié le domaine public. Bon, à part m'énerver la plupart du temps, 
ça résout pas grand chose.

JB.

Le 30/12/2015 18:20, f.dos.san...@free.fr a écrit :

Pour moi pas de doute si c'est marqué chemin privé -> access=private.
J'utilise access=destination pour les cas "sens interdit sauf riverains".

- Mail original -
De: "Jean-Claude Repetto" 
À: talk-fr@openstreetmap.org
Envoyé: Mercredi 30 Décembre 2015 17:33:51
Objet: Re: [OSM-talk-fr] Chemin privative

Bonjour,

Le 30/12/2015 16:37, f.dos.san...@free.fr a écrit :

Route à accès privé tag à ajouter : access=private
Et noeud (sur la route) à la position où est présente la grille : barrier=gate



A propos, une voie d'accès à un lotissement, marquée "chemin privé",
mais sans barrière, doit-elle être étiquetée en
access=private
ou
access=destination ?

Jean-Claude


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

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



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


Re: [Talk-cz] Tag "network" na pěších turistických trasách

2015-12-30 Per discussione Pavel Machek
Ahoj!

> Tohle ale asi neni bezne nebo ano? Pokud jsou to jednotky vyjimek, tak
> se to muze osetrit polo/rucne.
> 
> Na zaklade ceho jsi usoudil, ze je to jedna cervena a ne nekolik
> ruznych cervenych? (to neni rypani, ale snazim se vytahnout nejake
> podklady proc to tak je - min. vnimano). Ciste prakticky by znacka
> mela byt na obou koncich ukoncena ctvereckovou znackou zacatek/konec
> turisticke trasy, casto to tak asi je, ale urcite to casto bude proste
> vynechano. Pak se lze orientovat podle rozcestniku, ale kdyz se znacka
> deli na dve, tak je to ta stejna, nebo dve nove se stejnou barvou...

I kdyby tam mela ty ctverecky, tak bych se pro ucely nwn/rwn/lwn
tvaril ze je to jedna znacka, a dal ji vyssi dulezitost.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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


[Talk-es] Toyota quiere convertir a todos sus coches en mapeadores

2015-12-30 Per discussione Luis García Castro
¿Qué os parece esta noticia?

http://www.cnet.com/news/toyota-wants-to-make-google-mapping-tech-obsolete/

-- 

Luis García Castro
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es


Re: [OSM-talk] If a school is a shelter when a disaster happens...

2015-12-30 Per discussione Maarten Deen

On 2015-12-30 16:33, Dongpo Deng wrote:

Hi all,

There is a problem for tagging shelters. In Taiwan, some of schools
are selected to be shelters for villages or small regions when a
disaster happens. However, it is conflict to annotate two amenities on
a geometry object. That is, we cannot simultaneously use amenity =
school and amenity = social_facility; social_facility = shelter for a
school with shelter functionality.

Some Taiwanese mappers proposed to add 'emergency' as prefix for
distinguishing shelter, e.g.,
emergency : amenity =  amenity
emergency : social_facility = shelter

http://www.openstreetmap.org/relation/4790949

I'm just wondering if it is a good manner for this case. Because the
tag 'emergency' is used for emergency facilities but not including
shelters. Thus, adding emergency prefix to amenity is suitable? Any
suggestions for such situation?


How about shelter=emergency?
I don't really see why social_facility would be applicable. I don't see 
why an emergency shelter would be connected to social services.


Regards,
Maarten


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


Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione David Crochet

Bonjour

Le 30/12/2015 16:08, Damien a écrit :

Comment puis je modifier ou indiquer ce probléme (chemin avec un code
couleur specifique, ajout d'une barrière,...)


access=private ?

Cordialement

--
David Crochet

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


Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione f . dos . santos
Pour moi pas de doute si c'est marqué chemin privé -> access=private.
J'utilise access=destination pour les cas "sens interdit sauf riverains".

- Mail original -
De: "Jean-Claude Repetto" 
À: talk-fr@openstreetmap.org
Envoyé: Mercredi 30 Décembre 2015 17:33:51
Objet: Re: [OSM-talk-fr] Chemin privative

Bonjour,

Le 30/12/2015 16:37, f.dos.san...@free.fr a écrit :
> 
> Route à accès privé tag à ajouter : access=private
> Et noeud (sur la route) à la position où est présente la grille : barrier=gate
> 


A propos, une voie d'accès à un lotissement, marquée "chemin privé",
mais sans barrière, doit-elle être étiquetée en
access=private
ou
access=destination ?

Jean-Claude


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

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


Re: [OSM-talk-fr] JOSM modifier icône souris

2015-12-30 Per discussione lenny.libre
Je ne cherche pas à savoir dans quel mode je suis ; ce que j'aimerais 
c'est pouvoir le modifier car là, http://www.cjoint.com/c/ELErY4zqLEh, 
je ne vois plus les deux points que je veux superposer.


Le 30/12/2015 16:11, Jo a écrit :

L'icône du souris change en fonction du mode de travail.

Flêche pour sélectionner, lasso, si on fait 's' denouveau
Rectangle en mode 'bâti'.

Si tu vois une croix, tu es en mode 'ajouter' ou improve way accuracy.

Jo

2015-12-30 15:22 GMT+01:00 lenny.libre >:


Bonjour
L'icône de ma souris a une forme de flèche.
Il ne change pas lorsque je sélectionne un objet.
Par contre, si je déplace un point sélectionné, il se transforme
en croix qui me cache ce qui se trouve dessus.
Parfois, si je veux le placer sur un point existant, je n'arrive
pas à le placer précisément et quand je fusionne les points, celui
sur lequel je voulais me placer se déplace vers celui que je viens
de rapprocher (légèrement, mais ...).
Si je savais comment modifier cet icône, j'apprécierais ; j'ai
fait une recherche mais je n'ai pas su trouver.

cordialement et bonnes fêtes
Lenny

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


Re: [OSM-talk-fr] JOSM modifier icône souris

2015-12-30 Per discussione Vincent de Château-Thierry


Le 30/12/2015 18:56, lenny.libre a écrit :

Je ne cherche pas à savoir dans quel mode je suis ; ce que j'aimerais
c'est pouvoir le modifier car là, http://www.cjoint.com/c/ELErY4zqLEh,
je ne vois plus les deux points que je veux superposer.


Est-ce que c'est apparu récemment ? En voyant ta copie d'écran ça ne me 
dit rien personnellement. Quand je déplace un point sélectionné j'ai une 
petite main blanche qui "agrippe" l'objet que je déplace.
Une suggestion (mais pas une solution) : reporter la situation aux 
développeurs de JOSM via le menu Aide > Signaler une erreur.


vincent

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


Re: [Talk-it] Mappatura linea bus primo tentativo

2015-12-30 Per discussione Claudio Baraldi
Ho completato la prima linea Bus a Modena, con le varianti, fermate su 
entrambi i lati, ecc. e alla fine ho incorporato tutto in questa 
relazione "master" *5812481 *, credo di aver fatto tutto bene ma un 
controllo sarebbe gradito.
Praticamente ci ho messo una settimana tra rilievi sul posto e lavoro su 
Josm, pensavo fosse più semplice, proseguirò con le altre linee tempo 
permettendo.
Ho visto il rendering "trasporti" di OSM, la prima linea bus è comparsa 
quasi subito le altre non le vedo ancora, ogni quanto si aggiorna?


Grazie
Baldorider
(Claudio Baraldi)


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


Re: [OSM-talk-fr] Jointure attributaire dans JOSM

2015-12-30 Per discussione Jean-Marc Liotier
 

On 2015-12-30 13:49, Tony Emery wrote: 

> Du coup, il n'y a pas d'outils capable de relier la couche osm (A) à un jeu
> de données (B) afin de mettre à jour un tag de (A) avec la valeur présente
> dans la table (B)...

Avec ton langage de script préféré: dans le XML Openstreetmap pour
chaque objet concerné (XMLlib to the rescue !) lit la valeur de
l'attribut concerné, cherche là dans le jeu de données puis met à jour
l'attribut souhaité... J'apprends doucement à faire ce genre de choses
avec Perl - les premières fois ça coute beaucoup de temps mais la courbe
d'apprentissage est plaisante et c'est autrement plus industrialisable
qu'une manipulation dans une IHM graphique. 
 ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione Jean-Claude Repetto
Bonjour,

Le 30/12/2015 16:37, f.dos.san...@free.fr a écrit :
> 
> Route à accès privé tag à ajouter : access=private
> Et noeud (sur la route) à la position où est présente la grille : barrier=gate
> 


A propos, une voie d'accès à un lotissement, marquée "chemin privé",
mais sans barrière, doit-elle être étiquetée en
access=private
ou
access=destination ?

Jean-Claude


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


Re: [Talk-es] Toyota quiere convertir a todos sus coches en mapeadores

2015-12-30 Per discussione Jesús Gómez Fernández
Es algo que Steve Coast ya comentaba en su blog hace unos meses. En este
caso él hablaba de una iniciativa similar que tiene Tesla y lo compara con
el "viejo" y caro modelo de realizar mapas capturando datos a partir del
despliegue de una flota vehículos propios, tipo Google.
Además elimina dependencia con el proveedores de mapas.

http://stevecoast.com/2015/10/15/tesla-maps-and-the-exploding-future-of-map-data/


2015-12-30 17:10 GMT+01:00 Luis García Castro :

> ¿Qué os parece esta noticia?
>
> http://www.cnet.com/news/toyota-wants-to-make-google-mapping-tech-obsolete/
>
> --
>
> Luis García Castro
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es


[Talk-ca] weeklyOSM 284

2015-12-30 Per discussione Jinal Foflia
The weekly round-up of OSM news, issue # 284 is now available online in
English, giving as always a summary of all things happening in the
OpenStreetMap world:


*http://www.weeklyosm.eu/archives/6538
*


*Highlights of the weeklyOSM*

- Want to increase the speed of editing in JOSM? User baditaflorin has
created a cheat sheet to help us in doing so
*… **-  *Want to know more about "Roads
to Rome" ? Look for the interview with Raphael Reimann …

- Calling all couchmappers at the end of the year: Please click once, sit
back and enjoy the beauty of the world … 
- Mapzen has a Christmas present for all the users …

- Toyota wants to make Google’s mapping tech obsolete …


Enjoy!

weeklyOSM is brought to you by ...
https://wiki.openstreetmap.org/wiki/WeeklyOSM

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


Re: [Talk-it] Mail nuovi utenti

2015-12-30 Per discussione girarsi_liste
Il 30/12/2015 19:00, Andrea Lattmann ha scritto:
> Ciao a tutti, è da un pò che ci penso e chiedo il vostro aiuto. La mia idea è 
> questa: vorrei mandare un messaggio di benvenuto con una breve "guida" con 
> link al Wiki di OSM, strumenti e tutto il necessario, pregandoli anche di 
> iscriversi in ml, da spedire a tutti i nuovi mappers, visto che giornalmente 
> mi arrivano le notifiche dei nuovi iscritti. Questo per creare comunità, 
> evitare import senza sapere che bisogna seguire delle regole ecc. Ecc. Idee, 
> proposte, bozze?
> Se per voi è una boiata pazzesca lascio stare...
> 
> Andrea Lattmann
> 
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
> 

Prepara una sandbox, poi si può riflettere, come l'hai detta è una cosa
introduttiva da valutare insieme a questa:

http://wiki.openstreetmap.org/wiki/IT:Contribute_map_data


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



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


Re: [OSM-talk-fr] JOSM modifier icône souris

2015-12-30 Per discussione David Crochet

Bonjour

Le 30/12/2015 18:56, lenny.libre a écrit :

e ne vois plus les deux points que je veux superposer.


Tu dé-zommes, tu sélectionnes un nœud et « M » pour superposer les nœuds.

Cordialement

--
David Crochet

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


Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione jean navarro

Bonjour
si vous n’êtes pas un contributeur, vous pouvez quand même suggérer une 
modification sur la carte http://www.openstreetmap.org

à droite, il y a un bouton : "Suggérer une amélioration sur la carte"

cordialement
jean

Le 30/12/2015 16:08, Damien a écrit :

Bonjour,

J'utilise Openstreetmap pour créer mes itinéraires de randonnées vélo.
Plusieurs fois, je me suis retrouver sur des routes privatives fermées
par une grille. Le chemin indiqué sur la carte existe mais il n'est pas
empruntable .

Comment puis je modifier ou indiquer ce probléme (chemin avec un code
couleur specifique, ajout d'une barrière,...)

Merci de votre aide


___
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: [OSRM-talk] OSRM 4.9.0 released

2015-12-30 Per discussione Daniel Patterson
Hi Kin,

  The "from_osm_id" and "to_osm_id" must be two directly connected OSM node 
IDs.  The wiki page:

https://github.com/Project-OSRM/osrm-backend/wiki/Traffic 


  has some more details on the values, and some usage examples.

daniel

> On Dec 30, 2015, at 9:41 AM, Aurélien   wrote:
> 
> Hi,
> 
> When you define the CSV file structure "from_osm_id;to_osm_id;edge_value", 
> what means the "osm_id" ? Two vertex of an edge or a set of connected edges ?
> 
> For example, e is an edge and n a vertex :
> 
> n1 ---(e1)--- n2 ---(e2)--- n3 ---(e3)--- n4 
> ---(e4)--- n5
> 
> Should we make a CSV file with 4 lines (n1-n2, n2-n3, n3-n4, n4-n5) or one 
> line (e1-e4) ?
> 
> Thank you very much for your work, and happy new year in advance !
> 
> Kin
> 
> On Thu, Dec 24, 2015 at 12:42 PM, Patrick Niklaus 
> > 
> wrote:
> # Overview
> 
> `4.9.0` is a massive release with 198 files being touched, 8501 lines
> added, and 6308 deleted.
> This release features experimental support for traffic updates based on CH.
> It is an experimental feature and will most likely be subject to
> change. Some instructions
> to get traffic updates running can be found int the wiki
> [here](https://github.com/Project-OSRM/osrm-backend/wiki/Traffic 
> ).
> This release also features support for 64 bit OSM node ids. This
> drastically increases the disk space needed for pre-processing. Server
> memory usage is not affected. In preparation for the upcoming API
> re-write in `5.0` some smaller API breakges were introduced in this
> release. Leaflet-Routing-Machien 2.6.1 is compatible with the new API.
> As always this node-osrm 4.9.0 can be found on npm as well.
> 
> # Changelog
> 
> ## API changes:
> - BREAKING: Changed response code for ok to `200`
> - BREAKING: Fix off-by-one in via_indices (was one index too high)
> - BREAKING: Removed `osrm/server_path.hpp`
> - Add max value for viaroute and trip to osrm-routed. Default: 500 for
> viaroute and 100 for trip
> - Allow POST request without POST data
> - Add response code 208 for no segment found (important for bearing filter)
> - New temporary file `.level` created by osrm-prepare (see level caching)
> - New temporary file `.edge_segment_lookup` and `.edge_penalties`
> created by `osrm-extract` if passing the `--generate-edge-lookup`
> options.
> - API grammar got more strict to discard invalid requests faster.
> Options like `hint`, `u` and `b` now need to follow directly after a
> `loc` (or `src` and `dst`). Example:
> `=..=true=0,10=...=false=...`. The following is
> illegal: `=..=..=...=0,10=true=false`.
> - Pre-turn bearing is now available in the `route_instructions` array
> as last field
> - Remove short option name `-m` from `osrm-routed` as it conflicted
> - New option `--segment-speed-file` for `osrm-prepare`. CSV file using
> `from_osm_id;to_osm_id;edge_value`.
> 
> ## Bug fixes:
> - Support 64bit OSM node ids
> - Fixed u-turn penalty, value from lua profiles was not used
> - Fix street name corruption for large datasets
> - Properly initialize UUID used in Fingerprint class.  Fixes #1721
> 
> ## Maintenance:
> - Rewrite nearest neighbor search code
> - Rewrite via-route search and fix multiple related bugs
> - Add test for small component snapping
> - Update variant library which fixes GCC 5.1.2 compile errors
> - Silence warnings with GCC, LTO does not yet respect the -isystem switch
> - Use ccache by default if available and a suitable compiler is used.
> - Switch Travis builds over to trusty for Linux
> - Fix pkgconfig cmake template
> 
> ## Features:
> - Support general nxm queries to table query (thanks to @fab-girard)
> `loc`, `dst`, `src` parameters
> - Add edge update step to `osrm-prepare`. Enables fast edge weight updates
> - Add level caching `--level-cache` for `osrm-prepare`. This allows to
> speed up consecutive runs of `osrm-prepare` **on the same dataset**
> (only edge weights updates allowed).
> - Small component size is now configurable over parameter for `osrm-routed`
> - Support adding bearing filtering. Use `b=BEARING,RANGE`
> - Add support for advisory speed limits
> - Add duration and distance fields to `match` response
> - Human-readable error messages for out of memory
> - Include (road) name of matched nodes in addition to coordinate.
> - Add `is_startpoint` property to `result` ways in the lua profiles.
> Determines if a way can be a start point for a route (e.g. is set to
> `false` for ferry ways).
> 
> # Thanks
> 
> Thanks to all the contributers of this release:
> 
> - Arne Kaiser
> - Daniel J. Hofmann
> - Daniel Patterson
> - Fabien Girard
> - Johan Uhle
> - Jordan Markov
> - Kal Conley
> - Lauren Budorick
> - Moritz Kobitzsch
> - Rohan Paranjpe
> 
> Cheers,
> Patrick
> 
> 

Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione osm . sanspourriel

Sur le chemin :
access=private
Pour voir la grille et cie :
http://wiki.openstreetmap.org/wiki/Key:barrier
suivant ce qui obstrue


Le 30/12/2015 16:08, Damien - tatou...@gmail.com a écrit :

Bonjour,

J'utilise Openstreetmap pour créer mes itinéraires de randonnées vélo. 
Plusieurs fois, je me suis retrouver sur des routes privatives fermées 
par une grille. Le chemin indiqué sur la carte existe mais il n'est 
pas empruntable .


Comment puis je modifier ou indiquer ce probléme (chemin avec un code 
couleur specifique, ajout d'une barrière,...)


Merci de votre aide


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


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


Re: [Talk-GB] NLS OS 6in E in Potlatch & iD

2015-12-30 Per discussione Steve Doerr

On 30/12/2015 18:09, Tom Hughes wrote:

On 30/12/15 17:04, Steve Doerr wrote:

On 03/01/2015 17:47, Tom Hughes wrote:


They changed the URL for that layer recently when they merged the
separate England+Wales and Scotland layers for the 2nd edition 6 inch
maps into one layer. I've updated the wiki, but this should work:

tms:http://nls-{switch:0,1,2,3}.tileserver.com/os_6_inch_gb/{zoom}/{x}/{y}.jpg 





Changed again?


Yes, it's now behind an API key because that is one of the layers they 
are now selling access to:


http://maps.nls.uk/projects/subscription-api/



OK. Well, this worked for me: 
http://nls-0.tileserver.com/fpsUZbxtgtkn/{zoom}/{x}/{y}.jpg


--
Steve

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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


Wochennotiz Nr. 284 22.12.–28.12.2015

2015-12-30 Per discussione wnreader
Hallo,

die Wochennotiz Nr. 284 mit allen wichtigen Neuigkeiten aus der OpenStreetMap 
Welt ist da: 

http://blog.openstreetmap.de/blog/2015/13/wochennotiz-nr-284/

Viel Spaß beim Lesen!



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


Re: [Talk-dk] Copyright

2015-12-30 Per discussione Niels Elgaard Larsen


Nico:
> Copyright og ophavsret går gå formuleringer, og sammenstillinger, men
> viden og informationer er fri.

Ja, fakta som fx åbningstider, telefonnumre og den slags er ikke et problem.

Lov om ophavsret har en beskyttelse af databaser:

==
§ 71. Den, som fremstiller et katalog, en tabel, en database eller
lignende, hvori et større antal oplysninger er sammenstillet, eller som
er resultatet af en væsentlig investering, har eneret til at råde over
det pågældende arbejde som helhed eller en væsentlig del deraf ved at
fremstille eksemplarer af det og ved at gøre det tilgængeligt for
almenheden.
==

Det er en implementation af EU's InfoSoc-direktiv, så andre EU-lande har
tilsvarende regler.

Jeg mener ikke at de skulle være et problem at søge på informationer
enkeltvis. For at komme i problemer skulle man nok fx skrive en robot,
der fandt samtlige åbningstider hos Visitdenmark, Tripadvisor, osv og
opdaterede OSM med dem.

Men for en sikkerheds skyld er det nok meget godt at bruge forskellige
kilder og søgemaskiner.

På min restaurantside
http://digitalfrihed.dk/restaurants/missing.html
er der fx nu søgelinks til Duck Duck Go

> Dvs. konkrete informationer kan altid
> viderebringes, men man  må ikke kopiere større tekster og formuleringer.
> Undtagelsen er citatretten som er rimelig elastisk. (f.eks. bragte
> Politiken hele Ritts dagbog   under citatretten for nogle år siden).


Nej, det gjorde Politiken ikke.
Tøger Seidenfaden fik en betinget fængselsstraf og Politiken måtte
betale en millionbod.

> Den 29. december 2015 kl. 17.35 skrev Michel Coene
> >:
> 
> Lidt udvidet info: Domstoler behandler typisk to typer sager: civil
> sager og straffesager. Hvis du kaster en mursten igennem mit vindue,
> er det et civil sag. Politiet kan og må ikke gøre noget medmindre
> jeg (eller en anden, e.g. mit forsikring selskab) anmelder dig og
> kræver at du betaler for skaden.  Hvis vi ender foran et domstol
> skal jeg kunne bevise at jeg har led skade, og du er ansvarlig. 
> Hvor meget musik selskaber nu også gerne vil have dig til at tror på
> det, der er ingen politibetjente i gang med at tjekke om du ulovlig
> downloader Adele.  Musikselskaberne skal selv gøre det, og så skal
> de anmelde dig til politiet.   Det er derfor man aldrig hører om
> retssag: de skal kunne bevise at det er dig, og ikke en nabo som har
> gættet sig til dit WIFI password.  Hvad de gør i praksis er at få
> deres advokater til at skrive truende breve og håber at du går med
> til at betale dummebøde.  Så selv hvis restaurant ejeren spiser for
> meget sjove champignoner og slæber dig i retten, skal han kunne
> bevise at du har voldt ham skade.  Det bliver godt nok oppe ad
> bakken.  Google til gengæld, kunne betragte OSM som en konkurrent. 
> Det er også derfor du ikke må kopiere af Google maps.   Straffesager
> kræver ingen anmeldelse.
> 
> 2015-12-29 14:12 GMT+01:00 Michel Coene  >:
> 
> Copyright  er ikke en forbrydelse som sprit kørsel. Du kan kun
> ende i retten hvis en person eller virksomhed anklager dig for
> det. Google kunne teoretisk klager over at du støvsuger deres
> hjemmeside, men et restaurant vil nok næppe klage over gratis
> reklame.
> 
> Michel Coene
> 
> Op 29-dec.-2015 14:04 schreef "Tobias Stenby Brixen"
> >:
> 
> Hej, jeg har et par spørgsmål i forbindelse med hvordan man
> finder information til brug i OSM.
> 
> Er det ok at:
> 1) tage fx åbningertider fra restauranternes egne
> hjemmesider, hvor der er et copyright symbol på hjemmesiden?
> 2) tage fx åbningertider fra restauranternes egne
> hjemmesider, hvor der ikke er et copyright symbol på
> hjemmesiden?
> 3) bruge Google søgning (eller anden søgemaskine) til at
> finde frem til en restaurants hjemmeside?
> 
> Og til sidst et lidt andet spørgsmål: Er det muligt at søge
> i talk-dk’s arkiver?
> 
> På forhånd tak.
> 
> —
> Tobias Stenby Brixen
> 
> 
> 
> 
> 
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-dk
> 
> 
> 
> 
> -- 
> Michel Coene
> Georginehaven 94
> Dk-2765 Smørum
> 
> +45 52339625 
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-dk
> 
> 
> 
> 
> ___
> Talk-dk 

Re: [Talk-cz] Tahák klávesových zkratek editoru JOSM

2015-12-30 Per discussione xtompok
Ahoj,
Pekne. Mam  bug report na F4.
Jethro

30. prosince 2015 17:54:53 SEČ, "Marián Kyral"  napsal:
>Ahoj,
>moc se mi zalíbil vánoční dárek od Florina Badity [1]. Dokonce tak, že
>jsem jej přeložil do češtiny, pár věcí doplnil a trochu poupravil.
>Musel jsem se poprat s Inkscape, ale s pomocí strýčka Googla to dopadlo
>dobře. Takže jsem se zase něco nového naučil.
>
>No a protože jsem lidumil, tak jsem výsledek hodil na github [2]   ;-)
>
>
>
>Verzi v rozlišení 300dpi lze stáhnout tady:
>https://raw.githubusercontent.com/mkyral/osm/master/JOSM_tahak/JOSM_Keyboard_Layout_CZ_final_300dpi.png
>
>[1] http://www.openstreetmap.org/user/baditaflorin/diary/37606
>[2] https://github.com/mkyral/osm/tree/master/JOSM_tahak
>
>Marián
>
>
>
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz

-- 
Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte prosím moji 
stručnost.___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Per discussione Florent RICHARD
En parlant de mairie, ne faudrait-il pas modifier les mairies (bâtiment) sur 
ces communes fusionnées?


Je pensais à modifier le tag name
name=Mairie de  pour la mairie principale
name=Mairie annexe de  pour les autres mairies

Je pensais également à différencier la mairie principale et les mairies 
annexes par un tag spécifique.
J'ai vu qu'il existe un tag "townhall:type" sur le wiki anglais 
(http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtownhall) mais je ne suis 
pas sur que les valeurs "city" et "village" soient pertinentes.
Cette différenciation est peut-être superflue (je ne l'ai pas vu dans les 
mairies annexes de Nantes par exemple).


-Message d'origine- 
From: Tony Emery

Sent: Wednesday, December 30, 2015 4:08 PM
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

On a bien à faire à de futures mairies annexes des nouvelles communes...

"Ces communes déléguées n’ont pas le statut de collectivité territoriale,
seule la commune nouvelle est dotée de cette qualité. La mise en place de
ces communes déléguées permet également de créer une annexe de la mairie
dans laquelle sont établis les actes de l’état civil concernant les
habitants de la commune déléguée.

Ainsi, les bâtiments abritant actuellement les communes futures membres de
la commune nouvelle garderaient une utilité évidente et permettraient de
conserver un lien de proximité avec les habitants de l’ancienne commune."

courrierdesmaires.fr




-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-nouvelles-fusion-de-communes-tp5862292p5863524.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 



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


Re: [Talk-it] Qualche dubbio sui multipoligoni

2015-12-30 Per discussione Aury88
aldoct wrote
> Se i multipoligoni sono chiamati in questo modo dovrebbero contenere dei
> poligoni, appunto, annidati. 

per poligoni annidati intenti aree interne vuote? se è così non è
assolutamente necessario...multipoligono significa creare delle relazioni
per generare un poligono e una delle caratteristiche ottenibili tramite il
ruolo inner è quella di poter definire un confine interno ma non è
assolutamente obbligatorio che il multipoligono abbia dei ruoli inner 


> Questo almeno mi pare di aver capito leggendo il wiki. Perchè, dunque,
> vengono utilizzati per tracciare confini di parchi (Etna, Madonie ecc.) 
> assegnata a tratti di tali confini?

 i motivi sono tanti
le way non dovrebbero essere troppo estese come numero di punti,  anche se
questo non è obbligatorio è di sicuro una buona pratica.
un multipoligono è più difficile da rompere di un poligono e questo è tanto
più vero quanto più è esteso ...in un multipoligono il tagliare una way non
compromette l'integrità della relazione, con una way chiusa spezzandola in
un punto si compromette tutto...almeno a livello di render.
se una persona scarica una piccola area contenente un nodo appartenente al
confine nel caso di un multipoligono si scaricherà solo il tratto di way a
cui appartiene, nel caso del poligono scaricherebbe l'intero poligono con
estensione di chilometri e chilometri.
come ultimo punto  che mi viene in mente è che molti di questi tipi di
elementi hanno anche confini determinati giuridicamente/geograficamente da
elementi come strade o corsi d'acqua...questi rappresentano quindi veri e
propri confini e a mio avviso questo è reso più esplicito quando l'elemento
strada o fiume viene usato come confine in una relazione piuttosto che
sovrapponendo semplicemente la way perimetrale del parco 

> e come si deve interpretare la caratteristica "incompleto"

significa che hai scaricato solo parte della relazione...alcune way non sono
state scaricate e quindi risultano incomplete (incompleto non è un ruolo è
solo una segnalazione che alcuni dati non sono stati scaricati). è un
comportamento normale su josm e se vuoi nel tool per le relazioni hai la
possibilità di scaricare le way mancanti.

ciao e buon anno a te






-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/Qualche-dubbio-sui-multipoligoni-tp5863568p5863574.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: [OSM-talk-fr] Trouver le bati manquant

2015-12-30 Per discussione Laurent Combe
l'URL se "duplique" dans un second champ
dans ce champ elle devient "tms:tms[99]:fttps://api.map..."

il suffit d'enlever le premier "tms:" pour que l'url soit identique dans
les deux champs du formulaire

ensuite le nom que tu donnes importe peu (le tien est bon)

missingRoad ne ma rien apporté
par contre
celui qui permet de voir les batiments manquants est génial !

A+

Le 30 décembre 2015 à 09:45, Tony Emery  a écrit :

> Je ne sais pas si c'est pareil chez vous, mais moi, je n'arrive pas à
> ajouter
> ces tms.
>
> J'ai pourtant bien mis comme url
> tms[99]:
> https://api.mapbox.com/v4/pratikyadav.93f1df6f/{zoom}/{x}/{y}.png?access_token=pk.eyJ1IjoicHJhdGlreWFkYXYiLCJhIjoiMTA2YWUxNjRkNmFmZGQ4YzAxZWFiNDk0NDM1YjE1YjAifQ.4P6N5dNmA_WQXd3BsJvu5w
> et je l'ai nommé MapBox_MissingRoads.
>
> J'ai dû faire une erreur mais je ne vois pas où...
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Trouver-le-bati-manquant-tp5863259p5863472.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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] Ca va décoincer les moignons le travail à moyon

2015-12-30 Per discussione David Crochet

Bonjour

Au taf !

http://www.ouest-france.fr/leditiondusoir/data/645/reader/reader.html?t=1451494754671#!preferred/1/package/645/pub/646/page/11

Cordialement
--
David Crochet

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


Re: [Talk-cz] Tahák klávesových zkratek editoru JOSM

2015-12-30 Per discussione Marián Kyral
Dne 30.12.2015 v 20:14 xtom...@gmail.com napsal(a):
> Ahoj,
> Pekne. Mam bug report na F4.
> Jethro

Jaký? Nic špatného tam nevidím. Ta ikona je v pořádku, jestli myslíš tohle.

Marián

>
> 30. prosince 2015 17:54:53 SEČ, "Marián Kyral"  napsal:
>
> Ahoj,
> moc se mi zalíbil vánoční dárek od Florina Badity [1]. Dokonce
> tak, že jsem jej přeložil do češtiny, pár věcí doplnil a trochu
> poupravil.
> Musel jsem se poprat s Inkscape, ale s pomocí strýčka Googla to
> dopadlo dobře. Takže jsem se zase něco nového naučil.
>
> No a protože jsem lidumil, tak jsem výsledek hodil na github [2]   ;-)
>
>
>
> Verzi v rozlišení 300dpi lze stáhnout tady:
> 
> https://raw.githubusercontent.com/mkyral/osm/master/JOSM_tahak/JOSM_Keyboard_Layout_CZ_final_300dpi.png
>
> [1] http://www.openstreetmap.org/user/baditaflorin/diary/37606
> [2] https://github.com/mkyral/osm/tree/master/JOSM_tahak
>
> Marián
>
> 
>
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
> -- Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte
> prosím moji stručnost.
>
> ___
> 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] Karten-Projektion Merkator

2015-12-30 Per discussione Arne Johannessen
Martin Koppenhoefer  wrote:
> 
> 
> Google hat afaik nur das Slippymap-Prinzip erfunden, die Projektion ist von 
> Merkator.

Die von Google erfundene Variante der Mercator-Abbildung hat im Gegensatz zum 
"echten" Mercator Formverzerrungen (ist dafür aber billiger zu rechnen). Die 
Nordseeinsel Juist wird zum Beispiel rund 20 cm breiter dargestellt, als sie 
tatsächlich ist...

-- 
Arne Johannessen


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


Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione Philippe Verdy
C'est un lotissement avec une voie privée faisant partie des communs d'une
copropriété. Cas assez courant en fin de compte avec bon nombre de nouveaux
petits lotissements, le lotisseur faisant l'aménagement de la voie avant de
vendre les lots individuels viabilisés. Le nom de la voie est alors le nom
de la "résidence" ou du lotissement lui-même. Cependant une partie de cette
voie peut être encore publique, particulièrement s'il y a des commerces,
pour autoriser les accès par tous visiteurs au moins jusqu'au parking, même
s'il fait partie de la copropriété. (cependant son accès peut être ouvert
seulement à certaines heures et fermé la nuit par une barrière

Le 30 décembre 2015 à 17:33, Jean-Claude Repetto  a écrit
:

> Bonjour,
>
> Le 30/12/2015 16:37, f.dos.san...@free.fr a écrit :
> >
> > Route à accès privé tag à ajouter : access=private
> > Et noeud (sur la route) à la position où est présente la grille :
> barrier=gate
> >
>
>
> A propos, une voie d'accès à un lotissement, marquée "chemin privé",
> mais sans barrière, doit-elle être étiquetée en
> access=private
> ou
> access=destination ?
>
> Jean-Claude
>
>
> ___
> 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] fusion de régions

2015-12-30 Per discussione Philippe Verdy
Il n'y a aucune urgence d'autant que ces noms sont provisoires et toutes
les nouvelles régions doivent décider de leur nom avant l'été.

En attendant les noms actuels des régions actuelles suffisent bien, ces
régions sont encore celles référencées par les normes internationales, on
devra encore attendnre la mise à jour de l'ISO3166-2 pour les nouvelles
régions, mais les codes actuls continueront à désigner les régions
actuelles sans tenir compte du changement administratif. (En général
l'ISO3166-2 met un ou deux ans avant de refléter un changement): si les
noms n'arrivent qu'en juillet, on ne peut pas s'attendre à un changement
réel dans l'ISO3166-2 avant et cela s'appuiera sur une demande officielle
ou un document issu de l'INSEE, l'IGN ou dans un communiqué de la France à
l'Union européenne (qui finance aussi en partie les régions ou certains de
leurs programmes). Puis attendre que les comités ad hoc se réunissent pour
aprouver le changement.

On devra aussi attendre la codification INSEE des régions (et SIREN de leur
nouvelle collectivité réghionale et SIRET de leurs établissements
réaffectés dans la collectivité ou dissous) courant janvier, s'il y en a
une avant ll'entrée en application des nouveaux noms.
Ce qui change en fait c'est la partie administrative, pas la définition
géographique.


Le 29 décembre 2015 à 23:00,  a écrit :

> Visiblement la Normandie a perdu bien des tags des régions Haute- et
> Basse-Normandie.
> Par exemple les traductions.
> Certaines sont faciles (name:en=Normandy).
> Pour d'autres il faudra peut-être retrouver les auteurs des traductions
> des *-Normandie (ou sur Wikipedia).
>
> Pour "Nord-Pas-de-Calais et Picardie" il doit suffire de savoir dire "et"
> ;-).
>
> Jean-Yvon
>
> Le 29/12/2015 19:52, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> des relations existent déjà, elle sont tagué :
> boundary=administrative
> admin_level:proposed=4
>
> pour les voir :
> http://overpass-turbo.eu/s/dti
>
>
>
> ___
> 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] Trouver le bati manquant

2015-12-30 Per discussione Jean-Baptiste Holcroft
On a oublié le rendu QA de Christian sur tile.openstreetmap.fr ?
Il fait déjà tout à fait l'affaire avec un croisement cadastre vectoriel,
insee et osm.
Le 30 déc. 2015 13:51, "Tony Emery"  a écrit :

> Effectivement, ça marche. Par contre, soit il y a un décalage de la tuile
> par
> rapport aux données, soit la mise à jour des tuiles n'est pas fréquente...
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Trouver-le-bati-manquant-tp5863259p5863512.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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Per discussione osm . sanspourriel

Le 30/12/2015 12:29, Christian Quest - cqu...@openstreetmap.fr a écrit :
Je pense mal me faire comprendre... je ne parle pas d'une modélisation 
dans l'absolu "ex-nihilo" où oui, admin_level=9 me semblerait adapté. 
Je parle d'une utilisation actuelle des données qui va être 
potentiellement impactée si on ne prend pas en compte de nouveaux 
tags, impact qui serait beaucoup plus limité si on faisait ça sur 
admin_level=10 qui n'avait pas l'homogénéité de admin_level=9

Non, je pense que tu es clair.
Est-ce que des outils s'en servent vraiment ?
Comme dit par d'autres, les 3 cas, chacun différent, de 3 communes ne 
doivent pas empêcher de faire de bons choix pour 36 000 autres.



*? start_date=2016-01-01 ou end_date ou autre chose***
Mettre la plage temporelle dans le tag, ça les rend fort inutilisables 
si ce n'est pas rendu plus générique. J'avais proposé quelque chose du 
genre il y a un bout de temps, mais l'allergie ambiante aux données 
"historiques" avait eu raison de cette proposition.

Les tags que tu présente me semble une fausse bonne idée.

Quelqu'un a regardé comment c'est géré dans d'autres pays ?

Je ne fais que reprendre une idée venue d'ailleurs.
La personne la plus allergique en France sur les données historiques 
n'est pas sur cette liste il me semble ;-).
Le format est générique (attribut:dateISO=valeur, et en conservant le 
attribut=valeur pour la valeur actuelle).


admin_level=9 + disused:admin_level=8 ça pourrait aussi le faire, mais 
on n'a pas d'info sur la date de changement.

C'est bien le problème.
Maintenant si on met start_date=2016-01-01, admin_level=9, 
disused:admin_level=8, un humain comprendra sans doute ce qu'il doit 
comprendre.

Mais un ordinateur risque de ne rien afficher avant le 1er janvier.

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


Re: [OSM-talk-fr] Ca va décoincer les moignons le travail à moyon

2015-12-30 Per discussione Donat ROBAUX
Super travail de la mairie.
Sauf que je rigole quand je vois qu'ils ont gardé le nom de voie "rue de la
mairie". Avec le mouvement de fusion qu'il y a dans la Manche, c'est pas
dit qu'il n'y ait pas à terme plusieurs "rue de la mairie" et y aura plus
qu'à recommencer! lol

Sinon y a moyen de récupérer leur carto? (un petit mail?) D'ailleurs sur le
site de la mairie, ils affichent une carte "collaboration" sur fond G... 

Donat

-- Message transféré --
From: David Crochet 
To: "Discussions sur OSM en français" 
Cc:
Date: Wed, 30 Dec 2015 20:03:38 +0100
Subject: [OSM-talk-fr] Ca va décoincer les moignons le travail à moyon
Bonjour

Au taf !

http://www.ouest-france.fr/leditiondusoir/data/645/reader/reader.html?t=1451494754671#!preferred/1/package/645/pub/646/page/11

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


Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Per discussione osm . sanspourriel
> Cette différenciation est peut-être superflue (je ne l'ai pas vu dans 
les mairies annexes de Nantes par exemple).


Sur celles de Brest idem :
amenity  
townhall 


Seul le nom indique qu'il s'agit d'une mairie de quartier.

Sur le wiki allemand ils disent de mettre le type suivant si c'est une 
ville ou un district. Sans objet pour la France.


Spezifiziere auch näher: townhall:type 
=village 
für das Gemeindeamt einer Gemeinde townhall:type 
=city 
für das Rathaus einer Stadt.



Le 30/12/2015 20:10, Florent RICHARD - florentrich...@hotmail.fr a écrit :
En parlant de mairie, ne faudrait-il pas modifier les mairies 
(bâtiment) sur ces communes fusionnées?


Je pensais à modifier le tag name
name=Mairie de  pour la mairie principale
name=Mairie annexe de  pour les autres 
mairies


Je pensais également à différencier la mairie principale et les 
mairies annexes par un tag spécifique.
J'ai vu qu'il existe un tag "townhall:type" sur le wiki anglais 
(http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtownhall) mais je ne 
suis pas sur que les valeurs "city" et "village" soient pertinentes.
Cette différenciation est peut-être superflue (je ne l'ai pas vu dans 
les mairies annexes de Nantes par exemple).


-Message d'origine- From: Tony Emery
Sent: Wednesday, December 30, 2015 4:08 PM
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

On a bien à faire à de futures mairies annexes des nouvelles communes...

"Ces communes déléguées n’ont pas le statut de collectivité territoriale,
seule la commune nouvelle est dotée de cette qualité. La mise en place de
ces communes déléguées permet également de créer une annexe de la mairie
dans laquelle sont établis les actes de l’état civil concernant les
habitants de la commune déléguée.

Ainsi, les bâtiments abritant actuellement les communes futures 
membres de

la commune nouvelle garderaient une utilité évidente et permettraient de
conserver un lien de proximité avec les habitants de l’ancienne commune."

courrierdesmaires.fr




-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Communes-nouvelles-fusion-de-communes-tp5862292p5863524.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

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


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


Re: [Talk-it] Mappatura linea bus primo tentativo

2015-12-30 Per discussione Any File
2015-12-30 10:31 GMT+01:00 Claudio Baraldi :
> Devo dire che trovo notevole difficoltà a gestire il lavoro nel complesso:
> Josm non mi permette di scaricare dal server un'area sufficientemente ampia
> per coprire l'intero percorso per cui sono costretto a lavorare su porzioni
> del percorso e devo sempre ricordarmi di chiudere la relazione e salvare
> tutto (cio caricare nel server), prima di scaricare una nuova porzione di
> territorio altrimenti si creano conflitti e perdo il lavoro fatto.

Se ti limiti a scaricare un'altra area non dovrebbero crearsi dei conflitti.

I conflitti si creano se tu modifichi le way che sono citate nella
relazione mentre hai aperto la finestra per modificare la relazione o
se usi per altri motivi versioni non aggiornate (o delle way o delle
relazioni).  Solo alcune modifiche creano problemi: se semplicemnte
aggiungi dei nodi ad una way o se aggiungi dei tag ad una way non hai
problemi, ma se unisci, dividi o cancelli una way, possono sorgere
confilitti.

AnyFil

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


Re: [OSM-talk] If a school is a shelter when a disaster happens...

2015-12-30 Per discussione maning sambale
In the Ph, by default, schools are used as evacuation centers (which is bad
since it disrupts school days during prolonged crisis but thats a separate
discussion). For these, we tag them as amenity=school and
evacuation_center=yes.

cheers,

Maning Sambale (mobile)
On Dec 30, 2015 9:47 PM, "Maarten Deen"  wrote:

> On 2015-12-30 16:33, Dongpo Deng wrote:
>
>> Hi all,
>>
>> There is a problem for tagging shelters. In Taiwan, some of schools
>> are selected to be shelters for villages or small regions when a
>> disaster happens. However, it is conflict to annotate two amenities on
>> a geometry object. That is, we cannot simultaneously use amenity =
>> school and amenity = social_facility; social_facility = shelter for a
>> school with shelter functionality.
>>
>> Some Taiwanese mappers proposed to add 'emergency' as prefix for
>> distinguishing shelter, e.g.,
>> emergency : amenity =  amenity
>> emergency : social_facility = shelter
>>
>> http://www.openstreetmap.org/relation/4790949
>>
>> I'm just wondering if it is a good manner for this case. Because the
>> tag 'emergency' is used for emergency facilities but not including
>> shelters. Thus, adding emergency prefix to amenity is suitable? Any
>> suggestions for such situation?
>>
>
> How about shelter=emergency?
> I don't really see why social_facility would be applicable. I don't see
> why an emergency shelter would be connected to social services.
>
> Regards,
> Maarten
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[OSM-talk] weeklyOSM 284

2015-12-30 Per discussione Jinal Foflia
The weekly round-up of OSM news, issue # 284 is now available online in
English, giving as always a summary of all things happening in the
OpenStreetMap world:


*http://www.weeklyosm.eu/archives/6538
*


*Highlights of the weeklyOSM*

- Want to increase the speed of editing in JOSM? User baditaflorin has
created a cheat sheet to help us in doing so
*… **-  *Want to know more about "Roads
to Rome" ? Look for the interview with Raphael Reimann …

- Calling all couchmappers at the end of the year: Please click once, sit
back and enjoy the beauty of the world … 
- Mapzen has a Christmas present for all the users …

- Toyota wants to make Google’s mapping tech obsolete …


Enjoy!

weeklyOSM is brought to you by ...
https://wiki.openstreetmap.org/wiki/WeeklyOSM

Regards,
Jinal Foflia
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[Talk-us] weeklyOSM 284

2015-12-30 Per discussione Jinal Foflia
The weekly round-up of OSM news, issue # 284 is now available online in
English, giving as always a summary of all things happening in the
OpenStreetMap world:


*http://www.weeklyosm.eu/archives/6538
*


*Highlights of the weeklyOSM*

- Want to increase the speed of editing in JOSM? User baditaflorin has
created a cheat sheet to help us in doing so
*… **-  *Want to know more about "Roads
to Rome" ? Look for the interview with Raphael Reimann …

- Calling all couchmappers at the end of the year: Please click once, sit
back and enjoy the beauty of the world … 
- Mapzen has a Christmas present for all the users …

- Toyota wants to make Google’s mapping tech obsolete …


Enjoy!

weeklyOSM is brought to you by ...
https://wiki.openstreetmap.org/wiki/WeeklyOSM

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


Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione Jérôme Seigneuret
Le 30 décembre 2015 à 22:24,  a écrit :

> Si la gestion est privée mais que l'accès est libre (cas de bien des
> lotissements dans les 10 années suivant la construction), tu ne mets rien.
> Si tu veux vraiment, un operator=* ferait l'affaire.
>

hum non. Un access=permissive est plus correcte car le jour où ça leur
pête, ils mettront un portail et une clôture (déjà vu car la résidence
devenait un détour pour éviter les bouchons ;-) )



> Le 30/12/2015 19:27, Nicolas Moyroud - nmoyr...@free.fr a écrit :
>
> Le 30/12/2015 18:20, f.dos.san...@free.fr a écrit :
>
> Pour moi pas de doute si c'est marqué chemin privé -> access=private.
> J'utilise access=destination pour les cas "sens interdit sauf riverains".
>
> Moui sauf que quand c'est marqué "rue privée" tu fais quoi ? Des fois ça
> veut dire que c'est une rue qui n'est pas gérée par la collectivité locale,
> mais pas du tout que l'accès est privé. C'est le cas de la rue qui mène à
> mon lieu de travail elle est ouverte au public et elle dessert une bien
> belle brochette de lieux différents (labos de recherche, base de
> canoé-kayak, ...)
>
> Même cas.

*private *c'est dans le cas où il n'est pas permis de passer sauf par les
personnes ayant vocation à occuper ou gérer un lieu (délégation de pouvoir)

*access=permissive *permet l'accès avec revocation à tous moment. Quand un
panneau indique voie privé avec un sens interdit c'est que c'est pas
accessible sauf au occupant. Pour

Il y a les cas des servitudes d'accès (privé ou public) et dans d'autres
cas des accords d'exploitation d'une voie privé pour la collecte des
déchets par exemple ou pour l'accès aux riverains (permissive avec délais
contractuel et possibilité de révocation)

Ce sujet me rappel qu'il y a eu un mur construit en plein milieu d'une voie
en Bretagne.

Bonne soirée,
Jérôme


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


Re: [Talk-it] Mail nuovi utenti

2015-12-30 Per discussione michele iw1gfv
Il 30 Dicembre 2015 19:00:32 CET, Andrea Lattmann  ha 
scritto:
>Ciao a tutti, è da un pò che ci penso e chiedo il vostro aiuto. La mia
>idea è questa: vorrei mandare un messaggio di benvenuto con una breve
>"guida" con link al Wiki di OSM, strumenti e tutto il necessario,
>pregandoli anche di iscriversi in ml, da spedire a tutti i nuovi
>mappers, visto che giornalmente mi arrivano le notifiche dei nuovi
>iscritti. Questo per creare comunità, evitare import senza sapere che
>bisogna seguire delle regole ecc. Ecc. Idee, proposte, bozze?
>Se per voi è una boiata pazzesca lascio stare...
>
>Andrea Lattmann
>
Secondo me è un bella idea, a me avrebbe fatto piacere.
L'unica cosa da pensare bene, è come scriverla, perchè ovviamente tutti 
all'inizio sbagliano, la mail deve spiegare e motivare, non deve spaventare. o 
sembrare un rimprovero, perchè si rischia di perdere un mapper.

-- 
iw1gfv.it
piemontegps.altervista.org

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


Re: [OSM-talk-fr] Chemin privative

2015-12-30 Per discussione osm . sanspourriel
Si la gestion est privée mais que l'accès est libre (cas de bien des 
lotissements dans les 10 années suivant la construction), tu ne mets rien.

Si tu veux vraiment, un operator=* ferait l'affaire.

Jean-Yvon


Le 30/12/2015 19:27, Nicolas Moyroud - nmoyr...@free.fr a écrit :

Le 30/12/2015 18:20, f.dos.san...@free.fr a écrit :

Pour moi pas de doute si c'est marqué chemin privé -> access=private.
J'utilise access=destination pour les cas "sens interdit sauf 
riverains".
Moui sauf que quand c'est marqué "rue privée" tu fais quoi ? Des fois 
ça veut dire que c'est une rue qui n'est pas gérée par la collectivité 
locale, mais pas du tout que l'accès est privé. C'est le cas de la rue 
qui mène à mon lieu de travail elle est ouverte au public et elle 
dessert une bien belle brochette de lieux différents (labos de 
recherche, base de canoé-kayak, ...)


Nicolas

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


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


Re: [Talk-it] Mail nuovi utenti

2015-12-30 Per discussione Federico Cortese
Già che ci siamo qualcuno dovrebbe contattare angryrag
(https://www.openstreetmap.org/user/angryrag) per capire come mai come
primo edit ha deciso di promuovere Tricarico
(https://www.openstreetmap.org/node/67280376) da village a town.
Purtroppo capita spesso che nuovi utenti facciano questo tipo di
modifiche :(

Ciao
Federico

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


Re: [OSM-talk-fr] fusion de régions

2015-12-30 Per discussione Philippe Verdy
dans ta requête, l'option de la bounding box n'est pas sélective du tout et
ralentit tout. Autant la virer, le serveur répond alors immédiatement,
sinon pas moyen de voir quelquechose avec le timeout de 25 secondes
demandé, sauf si la bounding box est vraiment petite et qu'on tombe sur une
ou deux régions (donc impossible d'avoir une vue complète des régions)


Le 29 décembre 2015 à 19:52, Jérôme Amagat  a
écrit :

> des relations existent déjà, elle sont tagué :
> boundary=administrative
> admin_level:proposed=4
>
> pour les voir :
> http://overpass-turbo.eu/s/dti
>
> Le 29 décembre 2015 à 19:02, Philippe Verdy  a écrit :
>
>> On n'a aucune urgence d'autant que les nouvelles régions n'ont pas encore
>> de nom définitif (sauf la Normandie où c'est déjà décidé depuis un moment
>> et où tout le monde est d'accord sur le nom).
>> Il y a en fait peu d'urgence sur les régions, moins que les comunes
>> nouvelles (mais seulement si leur nouveau nom est vraiment original, sinon
>> on continue d'utiliser les aanciens noms pour les recherches ou la
>> géolocalisation).
>>
>> De plus le périmètre est connu largement. Ces grandes régions ont de
>> toute façon peu d'intérêt pour les recherches, elles sont trop grandes).
>>
>> Là où ce sera le bordel ce sera avec la disparition des départements,
>> pour promouvoir à la place les intercommunalités dans les régions, et
>> supprimer le rôle des préfets de départements (et sous-préfets qui n'ont
>> plus longtemps à vivre, ça viendra même avant la disparition des
>> départements car cet échelon ne sert vraiment à rien meêm pour l'Etat ou
>> ses services comme la police ou la justice; à la place des sous-préfets ce
>> sera le modèle parisien des préfets de police, la carte des tribunaux va
>> aussi changer encore, celles des services médicaux: en gros les services de
>> l'Etat ne seront plus liés à la structure administrative actuelle, il y
>> aura les collectivités locales et sinon les service répartis sur des zones
>> selon leur spécialité et les besoins réels, une fois transdférés plein de
>> services sur Internet de façon  dégéolocalisée.)
>>
>> On commence à voir la fin de la structure hiérarchique uniforme des
>> services déconcentrés de l'Etat (qui assume en fait de moins en moins de
>> choses en les transférant aux collectivités locales dont le rôle et les
>> compétences s'accroit en même temps que leur périmètre terriotorial). Ca
>> prend beaucoup de temps en France en comparaison des autres pays européens,
>> mais le modèle hiérarchique a vécu. et localement on aura de plus en plus
>> de compétences spécifiques et de "statuts particuliers", avec une plus
>> grande spécialisation des domaines de compétence pour éviter des doublons
>> de compétence. Et cette structure sera de plus en plus dyunamique avec des
>> modes de fonctionnement de plus en plus diférents selon les territoires.
>>
>>
>> Le 29 décembre 2015 à 17:57, Francescu GAROBY  a
>> écrit :
>>
>>> Je retire ce que j'ai dit : j'ai l'impression que les relations des
>>> (futures) région n'ont pas du tout été faites... En tout cas, je ne trouve
>>> pas la relation Normandie (fusion de la Basse et de la Haute-Normandie).
>>> Finalement, on n'est pas si en avance que ça...
>>>
>>> Francescu
>>>
>>> Le 29 décembre 2015 à 17:50, Francescu GAROBY  a
>>> écrit :
>>>
 Les fusions deviendront effectives au 01/01/2016. Tu es un peu en
 avance :-)

 Francescu

 Le 29 décembre 2015 à 17:40,  a
 écrit :

> juste pour rappeler que les régions apparaissent toujours sous leurs
> anciens contours.
> Bon, pour la Bretagne je m'occupe des changements - il n'y a pas de
> changement ;-).
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


 --
 Francescu

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


[OSM-talk] Bing Analyzer

2015-12-30 Per discussione Dale Kunce
I was doing some work tonight and I wanted to find the age of the Bing
tiles I was working with. I went to use the great Bing Analyzer TMS that
Ant did for his site a while back but it appears to be down.

Martijn's site still seems to be working but it doesn't have a proper TMS
from what I can tell.

Does anyone know of another good Bing Imagery TMS that I could use?

-- 

Dale Kunce
http://normalhabit.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


[Talk-ec] Semanario 284

2015-12-30 Per discussione Manfred A. Reiter
Hola, el semanario Nr. 284, el sumario de todo lo que está ocurriendo en el
mundo de OpenStreetMap está en línea en español

http://www.weeklyosm.eu/es/archives/6538

 ¡Disfruta!

WeeklyOSM en Español esta produzido por:

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


Re: [OSM-talk] If a school is a shelter when a disaster happens...

2015-12-30 Per discussione Dongpo Deng
Hi Maarteen and Maning,

Thank you guys for comments.

I agree with Marteen's opinion. The social_facility is difficult to be
applied for emergency. social_facility = shelter seems mostly to be used
for homeless people or refugees [1]. Thus, the wiki page of social_facility
= shelter [2] is really confused.

Maning's suggestion is great! I will recommend Taiwanese mappers to
use evacuation_center=yes
for this case. It's also good for regional tag consistency.

[1]
http://overpass-turbo.eu/?w=%22social_facility%22%3D%22shelter%22+global
[2] http://wiki.openstreetmap.org/wiki/Tag:social_facility%3Dshelter

Cheers,
Dongpo

On Thu, Dec 31, 2015 at 12:48 AM maning sambale 
wrote:

> In the Ph, by default, schools are used as evacuation centers (which is
> bad since it disrupts school days during prolonged crisis but thats a
> separate discussion). For these, we tag them as amenity=school and
> evacuation_center=yes.
>
> cheers,
>
> Maning Sambale (mobile)
> On Dec 30, 2015 9:47 PM, "Maarten Deen"  wrote:
>
>> On 2015-12-30 16:33, Dongpo Deng wrote:
>>
>>> Hi all,
>>>
>>> There is a problem for tagging shelters. In Taiwan, some of schools
>>> are selected to be shelters for villages or small regions when a
>>> disaster happens. However, it is conflict to annotate two amenities on
>>> a geometry object. That is, we cannot simultaneously use amenity =
>>> school and amenity = social_facility; social_facility = shelter for a
>>> school with shelter functionality.
>>>
>>> Some Taiwanese mappers proposed to add 'emergency' as prefix for
>>> distinguishing shelter, e.g.,
>>> emergency : amenity =  amenity
>>> emergency : social_facility = shelter
>>>
>>> http://www.openstreetmap.org/relation/4790949
>>>
>>> I'm just wondering if it is a good manner for this case. Because the
>>> tag 'emergency' is used for emergency facilities but not including
>>> shelters. Thus, adding emergency prefix to amenity is suitable? Any
>>> suggestions for such situation?
>>>
>>
>> How about shelter=emergency?
>> I don't really see why social_facility would be applicable. I don't see
>> why an emergency shelter would be connected to social services.
>>
>> Regards,
>> Maarten
>>
>>
>> ___
>>
> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-cz] Tag "network" na pěších turistických trasách

2015-12-30 Per discussione Jan Mladý
Reálné využití tagu network vidím v důležitosti/prioritě dané trasy která se dá 
použít i při vyhodnocení co se má v kterém zoomu vykreslit.
Viz například 
http://hiking.waymarkedtrails.org/cs/?zoom=13=50.68018=13.81599=0=0.745#routes
 

Bohužel ne všechny barvy odpovídají původnímu záměru co je lokální, regionální 
... vždy existují výjimky. Vcelku se mi líbí rozdělení podle délky trasy (jak 
ale vyhodnotit trasy které na sebe navazují, nemění barvu, pouze se mění číslo 
trasy (a tedy i relace)). Na rozdělení okresů bych se vykašlal a jako lwn bych 
dal opravdu jenom malé trasy do 5km (ano, pak většina bude rwn).

Honza Mladý alias mkačer

-Original Message-
From: Tom Ka [mailto:tomas.kaspa...@gmail.com] 
Sent: Wednesday, December 30, 2015 8:32 AM
To: OpenStreetMap Czech Republic 
Subject: Re: [Talk-cz] Tag "network" na pěších turistických trasách

Dne 29. prosince 2015 23:12 Václav Kubíček  napsal(a):
> Také souhlasím s klíčem OTM, jen s jednou menší úpravou, že žlutá by 
> patřila do "rwn" a do "lwn" bych nacpal různé místní a naučné stezky.
>
> Podobně to mají Slováci viz
> http://wiki.openstreetmap.org/wiki/WikiProject_Slovakia/Hiking_routes#
> Hiking_Routes_Networks_and_Numbering

Koukal jsem, ale prijde mi, ze i podle cisla cesty to KST pomerne striktne 
dodrzuje, pak to tedy dava smysl i pro "network".
U KCT viz komentar dole.

>> Rad bych tedy vyvolal nejakou diskusi nad exaktnimi pravidly 
>> oznacovani - tj. podle delky trasy, tim ze prochazi vice nez X okresy 
>> apod. Dovedu si predstavit neco takoveho (vykopavam, rozhodne 
>> netvrdim ze je to idealni nebo final):
>>
>> lwn: delka < 10km
>> rwn: delka > 10km, prochazi min. 2 okresy
>> nwn: delka > 50km, prochazi min. 2 kraji/3 okresy apod.
>
> Možná než se pustíme do téhle diskuse, tak by bylo dobré si ujasnit, 
> proč lwn/rwn/nwn vlastně chceme rozlišovat... má k tomu někdo nějaké 
> stanovisko? Mne by dávalo smysl to mít navázané na to, co za 
> kategorizaci používá správce značek, tedy KČT. Ostatně takhle to 
> děláme i s cyklostrasami.
>
> Pročež:
> Mohl by se někdo, kdo má kontakty do KČT, mohl zeptat, jestli ještě 
> pořád platí logika barev, jak platila dříve a jak byla i ostatně byla 
> navržena pro OpenTrackMap (OTM):
> červená – dálkové nebo hřebenové trasy modrá – významnější trasy 
> zelená – místní trasy žlutá– krátké trasy, spojovací cesty, zkratky 
> takto je to pořád ještě uvedeno i na Wikipedii:
> https://cs.wikipedia.org/wiki/Turistick%C3%A9_zna%C4%8Den%C3%AD_v_%C4%
> 8Cesku_a_na_Slovensku
>
> Pokud to KČT považuje za stále platné, tak bych se přikláněl k otmu to 
> nechat podle původního klíče OTM: červená nwn, modrá/zelená rwn, žlutá 
> lwn.

Podle meho nazoru a podle map to je asi porad platne pravidlo, ktere ale neni 
striktni ale spise zakladni doporuceni. Cast tras tak bude odpovidat, ale 
najdou se i takove, ktere pujdou proti. Za mne je tedy zakladni otazka, jestli 
tak "network" bude jen automaticky kopirovat jiny atribut (treba prave barvu) 
nebo bude definovan nezavisle - prave treba delkou trasy nebo poctem 
kraju/okresu apod. Za mne prvni varianta nedava moc smysl, resp. je to cisty 
duplikat a muze to doplnovat a opravovat/kontrolovat automat. Pro mappery je to 
pak nezajimave.

Proto jsem se ptal i na realne vyuziti, protoze podle toho by se dalo lepe 
rozhodnout, jak s tim nalozit a k cemu je to dobre.

Bye

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


Re: [OSM-talk-fr] Trouver le bati manquant

2015-12-30 Per discussione Tony Emery
Je ne sais pas si c'est pareil chez vous, mais moi, je n'arrive pas à ajouter
ces tms.

J'ai pourtant bien mis comme url
tms[99]:https://api.mapbox.com/v4/pratikyadav.93f1df6f/{zoom}/{x}/{y}.png?access_token=pk.eyJ1IjoicHJhdGlreWFkYXYiLCJhIjoiMTA2YWUxNjRkNmFmZGQ4YzAxZWFiNDk0NDM1YjE1YjAifQ.4P6N5dNmA_WQXd3BsJvu5w
et je l'ai nommé MapBox_MissingRoads.

J'ai dû faire une erreur mais je ne vois pas où...



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Trouver-le-bati-manquant-tp5863259p5863472.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-de] Semi-OT: Welches GPS fürs Fahrrad?

2015-12-30 Per discussione Volker Schmidt
Habe selbst keine Erfahrung, aber mich wundert, dass keiner ueber Garmin
edge Touring und edge 1000 spricht. Beide kommen von Hause aus mit
vorinstallierter OSM Karte (=Garmin Cycle Map) fuer ganz Europa.

Volker

This
email has been sent from a virus-free computer protected by Avast.
www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2015-12-30 8:57 GMT+01:00 Joerg Fischer :

> Sven Geggus wrote:
>
> > Wozu sich bisher noch niemand geäußert hat sind die speziellen Fahrrad
> > GPS-Geräte von Garmin.
> > Hat wirklich niemand von euch so eins?
>
> Ich hab den Thread nur mit 1/4 Auge verfolgt und schreibe jetzt ggf.
> Redundanz.  Ich habe ein Edge 705.  Vorteile: Ewige Akkulaufzeit (12 - 16
> h), Display auch bei voller Sonne gut ablesbar, am Lenker nicht so fett wie
> ein Smartphone.  Nachteile: Mickriges Display mit schlechter
> (Karten)auflösung, Navigation nicht mit Sprache sondern nur mit einem Pfeil
> auf dem Display und einem "Pieps". Speicherplatzbeschränkung auf 2 GB, da
> passt nicht mal die vollständige Deutschlandkarte rein.
>
> Für mich der inzwischen größe Nachteil ist die frickelige Selbsterzeugung
> der Karten.  Nicht nur, dass der ganze Prozess ein 'moving target' ist, der
> sich durch die Softwareupdates ständig ändert, insbesondere ist es mir zu
> umständlich mich immer wieder mit den Routingoptionen herumzuschlagen.  Vor
> allem fürs Rad ist das nicht trivial, auch wenn es den Vorteil hat das man
> persönliche Präferenzen (Asphalt, keine Hauptstraßen usw.) bei der
> Kartenerstellung berücksichtigen kann. Und bei den Karten zum herunter
> laden weiß man gleich gar nicht was für Präferenzen der Autor gesetzt
> hat...
>
> Ich benutze das Garmin inzwischen nur noch für die Streckenaufzeichnung und
> meine Trainingsstatistik.  Routing erledigt das Smartphone mit Osmand, mit
> der vollständigen Europakarte, monatlichen Kartenupdates, Sprachansage, und
> einem Display auf dem man - wenn nicht grad die Sonne scheint - auch etwas
> erkennen kann.
>
> VG Jörg
>
> --
> There are only 10 types of people in the world:
> Those who understand binary, and those who don't...
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


[OSM-talk-fr] Jointure attributaire dans JOSM

2015-12-30 Per discussione Tony Emery
Bonjour à tous,

Je voulais savoir si l'un d'entre vous a déjà essayer de faire une jointure
attributaire dans JOSM entre des données osm et une couche d'info (shape ou
autre) afin de mettre à jour les données OSM ?

Si oui, comment on fait ? Sinon, comment faites-vous pour faire ce genre
d'opération ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Jointure-attributaire-dans-JOSM-tp5863476.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-cz] Špatně vložené rozcestníky (old.openstreetmap.cz) - jak to opravit?

2015-12-30 Per discussione Marián Kyral
Ahoj,
tak jsem teď zase přidával pár rozcestníků. Naklikávání souřadnic,
zadání REF i odezva během nahrávání funguje skvěle. Takže zase pár
námětů na vylepšení ;-)

1) Okno na přidávání rozcestníků by si mohlo pamatovat autora - po novém
otevření tam vždy mám "autor" a musím to přepsat

2) Když si to okno otevřu, tak by se mohl výřez mapy sesynchronizovat s
aktuální polohou - takhle si najdu místo, kam chci rozcestníky přidávat,
mrknu, jestli tam už náhodou nejsou, pak otevřu okno na přidání a mapa
pokaždé ukazuje někam k Praze. Pokud nemám souřadnice v exifu, musím
znova hledat místo, kde chci přidávat.

3) K čemu přesně je to pole "Poznámka"? Co si tam můžu poznamenat?

4) Zobrazení rozcestníků - když kliknu na své jméno, hodí mně to na url
http://api.openstreetmap.cz/table/name/ a stránka
zůstane prázdná. Musím to přepsat na
http://api.openstreetmap.cz/table/name/mkyral abych viděl své rozcestníky.

Marián

Dne 9.11.2015 v 14:23 Michal Grézl napsal(a):
> 2015-11-05 19:21 GMT+01:00 Marián Kyral :
>> Ahoj,
>> tak jsem teď vkládal rozcestníky z víkendu (přes web) a hned u toho prvního
>> se mi povedlo zadat špatné ref a u dvou dalších špatné souřadnice (neměl
>> jsem je v exifu).
>>
>> Tak jsem hledal jak to opravit. Našel jsem editor, ale tam žádné opravy
>> nejdou. Navíc jsem zjistil, že se ani jedno ref. neuložilo :-(
>> Jsou to rozcestníky 3459 až 3466.
>>
>> A u těch dvou fotek rozcestníků bez souřadnic jsem na té náhledové mapě
>> dvakrát klikl na přibližné místo jejich umístění (mohlo by to jít ještě více
>> přiblížit) - vyplnily se souřadnice. Bohužel jsem si je nezkontroloval a z
>> editoru jsem zjistil, že se obě fotky nahrály se souřadnicemi někde v lese
>> :-(
>>
>> Jsou to rozcestníky 3468 a 3469. Správné umístěné je
>> http://www.openstreetmap.org/node/3814562080 a
>> http://www.openstreetmap.org/node/2298307768
>>
>> Můžeš to prosím opravit, případně mi poradit jak na to? (Jestli to je vůbec
>> možné). A je to chyba u mne, nebo na serveru? Používám Firefox 41.0.2 na
>> Gentoo.
> souradnice opraveny, zoom zvetsen na 18.
> Posilani refu bylo blbe udelane, melo by to byt opravene
>
>> A jak se vlastně to okno pro nahrávání na webu správně používá? Jak tam
>> případně naklikám ty správné souřadnice? Nebo si je musím zjistit jinde?
> Pokud ma fotka souradnice v exifu, necha se 0,0.
> Nebo se zaskrtne zaskrtavatko exif, coz ovsem pouze zmeni souradnice
> na 0,0 a zasedne je:).
>
>> Ještě návrhy, co by tedy chtělo zlepšit:
>>
>> *) umožnit větší přiblížení náhledové mapy
> done
>
>> *) vylepšit to naklikávání souřadnic - ideálně s nějakou vizuální odezvou a
>> možností daným bodem následně posouvat
> Posouvani bodu by mohlo byt narocnejsi, uvidime.
>
>> *) nějak lépe zviditelnit fakt, že bylo nahrávání dokončeno. Nevím jak to
>> mají ostatní, ale po kliknutí na "nahrát soubor" se mi dole, těsně pod
>> hranou toho dialogu, na chvíli objeví text o tom, že se nahrává a pak zmizí.
>> Ale v dialogu samotném se nic nezmění. Takže se mi stalo, že jsem se
>> pokoušel nahrát ten samý obrázek ještě jednou - to naštěstí nejde. Chtělo by
>> to ten dialog trochu roztáhnout, aby se tam vešlo všechno (asi se to
>> posunulo mimo po přidání políček pro ref) a po úspěšném nahrání rozcestníku
>> by se tam mohla objevit nějaká zelená fajfka a zároveň by se ten dialog
>> vyčistil (vyprázdnilo by se políčko s názvem souboru a ref) A kdyby se ta
>> mapa zároveň posunula na souřadnice toho nově nahraného rozcestníku, to by
>> bylo úplně boží ;-)
> Vizualni kontrola uploadu ,resetovani, posunuti - neni problem.
> Predelam ten dialog do jquery a pak bude mnohem jednodussi delat zmeny.
>
>> Ale úplně nejlepší by bylo umožnit nahrát více fotek najednou. Nejprve si
>> vyberu fotky, ty se nejprve nahrají na server na nějaké dočasné umístění, u
>> každé se zobrazí poloha na mapě dle exifu, případně tam bude žádost o zadání
>> souřadnic, pokud chybí exif. Zároveň budu mít možnost doplnit ref a změnit
>> typ. A až bude všechno hotovo, kliknu na tlačítko uložit, které změny uloží
>> do databáze. Pokud na uložit nekliknu, fotky se do databáze neuloží a po
>> nějaké době se smažou.
>>
>> Takhle to třeba funguje na Flickr.com.
> Je moznost domluvit se jednotlive na predani (upload, download)
> baliku. Atomaticky to urcite delat nebudu, nemam zdroje k umozneni
> nahravani gigovych fajlu.
>
>> V podstatě by stačilo nahrát fotky a zobrazit je v tom editoru (až ho
>> dopíšeš) :-D
>>
>> Jo a ještě, co takhle implementovat přihlašování pomocí
>> http://wiki.openstreetmap.org/wiki/OAuth ?
> Nejaka forma prihlasovani byt musi, to je jasne.
>
>> Pomohl bych, bohužel já a javascript se nemáme rádi.
>>
>> uff,
>> jsem se nějak rozepsal. Těm co dočetli až do konce gratuluji :-D
>>
>> Mapování a rozcestníků zvláště zdar.
>> Marián
>>


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


Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Per discussione Vincent de Château-Thierry

> De: "Tyndare" 
> 
> Sur tous les exemples que j'ai vu le tag ref:INSEE était indiqué sur
> le nœud place, (admin_center)
> Si le noeud place correspond au panneau
> du village et non a la commune le tag ref:INSEE n'a pas de sens ici,
> il faudrait le déplacer systématiquement sur la relation admin (pour
> toutes les communes de France)

La généralisation du tag ref:INSEE sur les nodes place=* date de 2012 [1], 
l'idée, comme rappelé par Stéphane, était de pallier l'absence des contours 
admins. C'est du passé, et en effet l'existence exaustive des contours 
permettrait de faire un peu de ménage. 

> Je suis mitigé pour basculer les codes INSEE historiques en old_ref
> Même si il ne sont plus actifs ils restent toujours plus ou moins
> valides.

Je les garderais aussi volontiers en ref:INSEE (et non old_ref:INSEE) mais il 
faut être conscient d'une nouvelle situation : une même valeur de code INSEE va 
s'appliquer à 2 emprises : une commune nouvelle, _et_ la commune déléguée qui 
prend le rôle de chef-lieu. Donc une requête sur uniquement le code INSEE ne 
ramènera plus un résultat unique, mais 2 emprises, l'une imbriquée dans 
l'autre, sauf à préciser l'admin_level qu'on cherche : admin_level=8 ramènera 
la commune nouvelle, admin_level=9 ramènera une commune déléguée.

vincent

[1] : https://lists.openstreetmap.org/pipermail/talk-fr/2012-April/042521.html

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


[OSM-talk-nl] Nieuwjaarsborrel zo 10 jan 2016, Dudok Hilversum

2015-12-30 Per discussione Just van den Broecke

Beste Mensen,

Voor het vijfde achtereenvolgende jaar (lustrum) de traditionele 
OSGeo.nl+OSM-NL Nieuwjaarsborrel voor iedereen die open source 
geo-software en OpenStreetmap een warm hart toedraagt.


Ook dit jaar weer in bovenzaal Cafe Dudok, Hilversum (t/o station NS), 
op zondag 10 jan 2016, vanaf 15:00.


Er is ruimte voor "talks". Jan-Willem van Aalst zal bijv 
vertellen over de gloednieuwe BGT-visualisatie voor de geplande OpenTopo 
3200pix/km.


Opgeven, ook voor "talks", via OSGeo.nl Meetup:
http://www.meetup.com/OSGeoNL/events/227097392

Hartelijke groet,

--Just

PS voor wie het gemist had, het verslag van NJ-Borrel 2015:
http://osgeo.nl/2015/01/nieuwjaarsborrel-2015-de-presentaties



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


Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Per discussione Philippe Verdy
Pour les old_ref, plutôt que d'ajouter un suffixe de date pourquoi ne pas
mettre la date ou l'intervalle de dates entre parenthèses après la
référence, avec en plus la possibilités de plusieurs refs anciennes
séparées par point-virgule avec chacune la mention de dates? Un seul tag
alors...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Per discussione Philippe Verdy
Pour les old_ref, plutôt que d'ajouter un suffixe de date pourquoi ne pas
mettre la date ou l'intervalle de dates entre parenthèses après la
référence, avec en plus la possibilités de plusieurs refs anciennes
séparées par point-virgule avec chacune la mention de dates? Un seul tag
alors...
Le 30 déc. 2015 10:45,  a écrit :

> pour les *old_ref:INSEE*, je serais plus pour des
> old_ref:INSEE:-2016-01-01=
> (millésimons ! ;-))
>
> Pour le *admin_level=9*, je ne vois pas à quoi tu fais référence : je
> trouve (j'ai regardé uniquement dans l'ouest) et je tombe sur des communes
> associées, déléguées..., bref des choses homogènes qui existent déjà, les
> outils existants ne devraient pas avoir des comportement inattendus.
> Tu ne penses pas au niveau ComCom qui n'est pas (plus) un niveau
> administratif et qui n'est pas de niveau 9 ?
> Les exceptions sont les arrondissements municipaux et ils sont bien une
> subdivision des trois communes PLM comme le sont les communes déléguées,
> donc au même niveau. Pas de même nature, d'où l'autre attribut.
>
> En ajoutant sur les communes devenues déléguées un tag spécifique style :
> *? **admin_type:FR=commune déléguée*
> on a moyen de changer sans problème.
>
> Ma requête :
> *relation[admin_level=9]({{bbox}})*
> * ); out center;*
>
> *? source=le JO ou l’arrêté préfectoral*
> Le JO c'est plutôt mieux, mais pour Audierne il n'était pas sorti
> (maintenant c'est JORFTEXT31690191)
>
> dep,nouvelle,anciennes,date,population,chflieu,jorf
> 29,Audierne,Audierne|Esquibien,,3839,Audierne,JORFTEXT31690191
>
>
> *? start_date=2016-01-01 ou end_date ou autre chose*
> (pour les communes déléguées)
> Comme c'est "seulement" le niveau administratif qui change, ça ma gène un
> peu de mettre un start_date ou un end_date.
> C'est pour cela que je proposais :
> admin_level:-2016-01-01=8
> admin_level:2016-01-01-=9
> (plus un admin_level=8 jusqu'à demain soir et 9 au delà,
> admin_level=8 et
> admin_level:proposed=9 permettent de scripter le changement à minuit)
> Comme ça les outils marchent (admin_level est correct) et on ne perd pas
> l'information.
> Mais comme dit Vincent, ça crée des tags en plus. Ceci dit, ça permet
> d'affiner. Allez, des volontaires pour faire une animation en CSS par
> exemple pour visualiser les changements ? Ça pourrait être parlant pour la
> promotion d'OSM auprès de la PQR ou des voisins de bureau de Christian.
>
> Jean-Yvon
>
>
> Le 30/12/2015 08:23, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Franchement, le admin_level=9 me gène pour la confusion qu'il va créer
> pour les outils l'utilisant déjà actuellement (et il y en a vu que ces
> découpages étaient exhaustifs).
>
> Je ne me battrais pas là dessus, mais ne vous étonnez pas si il y a des
> trucs qui merdent à court terme ici ou là.
>
> Sur le process, je propose de faire ça en deux temps et via le script que
> j'ai écrit:
> 1) création des nouvelles relations avec admin_level:proposed=8 /
> start_date=2016-01-01
> ça laisse un peu de temps pour vérifier...
> 2) bascule en admin_level=8 et modif des anciennes communes
>
> L'important étant d'avoir le CSV global bien propre. Le script permet
> d'être homogène et ne mobilise plus de temps humain qu'on peut remettre à
> profit sur le contrôle du résultat.
>
>
> relation commune délégués :
> type=boundary
> boundary=administrative
> name=*
> ? admin_level=9
> ? source=le JO ou l’arrêté préfectoral
> ? admin_type:FR=commune déléguée
> ? start_date=2016-01-01 ou end_date ou autre chose
>
> il faut bien sur tomber d'accord sur
> quel admin_level?
> tag spécifique oui(lequel?) ou non?
> le truc c'est que le tag spécial commune déléguée peut être facilement
> supprimé plus tard si on décide qu'il est inutile mais plus difficile a
> ajouté quant tous sera fini.
>
>
> Le 30 décembre 2015 à 00:46, Donat ROBAUX  a écrit :
>
>> Merci Jérome pour le lien. J'avoue ne même pas avoir pensé à consulter
>> WP... Ils sont vachement plus à jour que nous. Donc nous on est carrément à
>> la ramasse. Ils ont fouillé dans tous les RAA (pas eu le temps de passer
>> partout). Faut dire qu'ils ne sont pas très pratique à consulter.
>> Va falloir aller faire du pompage chez WP ;)
>>
>> Pour info et comme je disais dans un précédent mail: sur Légifrance, les
>> arrêtés étant publiés par date d'arrêté et non par publication au JO, j'ai
>> dû remonter jusqu'à la page 7. Des arrêtés datent de juillet et sont
>> publiés seulement le 29/12/2015. Tu m'étonnes que l'INSEE ne peut pas être
>> à jour... (re clin d’œil à Christian dans le cadre de la BAN).
>>
>> Donat
>>
>>
>>
>>>
>>> -- Message transféré --
>>> From: "Jérôme Amagat" 
>>> To: "Discussions sur OSM en français" 
>>> Cc:
>>> Date: Tue, 29 Dec 2015 20:56:15 +0100
>>> Subject: Re: [OSM-talk-fr] Communes nouvelles - fusion de communes
>>> pour la liste des communes nouvelles la page wikipedia 

Re: [Talk-it] Armchair mapping natalizio zone bisognose

2015-12-30 Per discussione Martin Koppenhoefer


sent from a phone

> Am 30.12.2015 um 10:40 schrieb girarsi_liste :
> 
> Siamo ancora in tempo? non ho visto date di termine mapping.


non finisce mai ;-)

ciao,
Martin 

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


Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Per discussione osm . sanspourriel

- parce que ce n'est pas un schéma conseillé
- parce que tu es obligé d'analyser de manière spécifique ces tags
- parce que les outils existants ne marcheront pas
- parce que la tendance est à avoir des attributs spécifiques et non des 
valeurs à rallonge. Ça s'analyse mieux.
- parce que lire des dates ISO, ce n'est déjà pas évident, alors des 
dates imbriquées dans des tags style admin_level=8 
(-2016-01-01);9(2016-01-01-)...
C'est comme les heures d'ouverture, sans un programme spécifique c'est 
inutilisable sauf que les heures d'ouvertures sont soit ignorées soit 
gérées. Le faire sur le code INSEE passe encore mais sur des données qui 
sont utilisées pour la visualisation des couches classiques...


Ma proposition suit un des schémas de cycle de vie proposés.


Le 30/12/2015 11:09, Philippe Verdy - verd...@wanadoo.fr a écrit :


Pour les old_ref, plutôt que d'ajouter un suffixe de date pourquoi ne 
pas mettre la date ou l'intervalle de dates entre parenthèses après la 
référence, avec en plus la possibilités de plusieurs refs anciennes 
séparées par point-virgule avec chacune la mention de dates? Un seul 
tag alors...


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


Re: [Talk-cz] Tag "network" na pěších turistických trasách

2015-12-30 Per discussione Václav Kubíček

U nás to taky tak fungovalo (viz odkaz níže), než si KČT vymyslel, že na 
rozcestníkách nebude značit čísla tras, ale čísla rozcestníků.
Nevím jestli si stále vede svojí evidenci číslování tras, ale k té my se asi 
bohužel nikdy nedostaneme...
https://cs.wikipedia.org/wiki/Turistick%C3%A9_zna%C4%8Den%C3%AD_v_%C4%8Cesku_a_na_Slovensku#Evidence_zna.C4.8Den.C3.BDch_cest
 
Vašek
__

Od: Tom Ka 
Komu: OpenStreetMap Czech Republic 
Datum: 30.12.2015 08:33
Předmět: Re: [Talk-cz]Tag "network" na pěších turistických trasách


Dne 29. prosince 2015 23:12 Václav Kubíček  napsal(a):

Také souhlasím s klíčem OTM, jen s jednou menší úpravou, že žlutá by patřila
do "rwn" a do "lwn" bych nacpal různé místní a naučné stezky.

Podobně to mají Slováci viz
http://wiki.openstreetmap.org/wiki/WikiProject_Slovakia/Hiking_routes#Hiking_Routes_Networks_and_Numbering
 



Koukal jsem, ale prijde mi, ze i podle cisla cesty to KST pomerne
striktne dodrzuje, pak to tedy dava smysl i pro "network".
U KCT viz komentar dole.


Rad bych tedy vyvolal nejakou diskusi nad exaktnimi pravidly
oznacovani - tj. podle delky trasy, tim ze prochazi vice nez X okresy
apod. Dovedu si predstavit neco takoveho (vykopavam, rozhodne netvrdim
ze je to idealni nebo final):

lwn: delka < 10km
rwn: delka > 10km, prochazi min. 2 okresy
nwn: delka > 50km, prochazi min. 2 kraji/3 okresy apod.


Možná než se pustíme do téhle diskuse, tak by bylo dobré si ujasnit,
proč lwn/rwn/nwn vlastně chceme rozlišovat... má k tomu někdo nějaké
stanovisko? Mne by dávalo smysl to mít navázané na to, co za kategorizaci
používá správce značek, tedy KČT. Ostatně takhle to děláme i s
cyklostrasami.

Pročež:
Mohl by se někdo, kdo má kontakty do KČT, mohl zeptat, jestli ještě
pořád platí logika barev, jak platila dříve a jak byla i ostatně
byla navržena pro OpenTrackMap (OTM):
červená – dálkové nebo hřebenové trasy
modrá – významnější trasy
zelená – místní trasy
žlutá– krátké trasy, spojovací cesty, zkratky
takto je to pořád ještě uvedeno i na Wikipedii:
https://cs.wikipedia.org/wiki/Turistick%C3%A9_zna%C4%8Den%C3%AD_v_%C4%8Cesku_a_na_Slovensku
 


Pokud to KČT považuje za stále platné, tak bych se přikláněl k otmu
to nechat podle původního klíče OTM: červená nwn, modrá/zelená rwn,
žlutá lwn.


Podle meho nazoru a podle map to je asi porad platne pravidlo, ktere
ale neni striktni ale spise zakladni doporuceni. Cast tras tak bude
odpovidat, ale najdou se i takove, ktere pujdou proti. Za mne je tedy
zakladni otazka, jestli tak "network" bude jen automaticky kopirovat
jiny atribut (treba prave barvu) nebo bude definovan nezavisle - prave
treba delkou trasy nebo poctem kraju/okresu apod. Za mne prvni
varianta nedava moc smysl, resp. je to cisty duplikat a muze to
doplnovat a opravovat/kontrolovat automat. Pro mappery je to pak
nezajimave.

Proto jsem se ptal i na realne vyuziti, protoze podle toho by se dalo
lepe rozhodnout, jak s tim nalozit a k cemu je to dobre.

Bye

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


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


Re: [OSM-talk-fr] Jointure attributaire dans JOSM

2015-12-30 Per discussione Christian Quest
Le plugin conflation détermine une proximité sémantique (tags
approchants) et on peut fixer une limite en distance.

Fonctionnement pas très évident, mais une fois maitrisé il fait gagner
beaucoup de temps.

Autre approche... le plugin todolist. Il permet de passer en revue une
sélection d'objets un à un. C'est plutôt ça que j'utilise pour
rapprocher plus manuellement des données.


On 30/12/2015 11:06, Frédéric Rodrigo wrote:
> Salut,
>
> Tu peux regarder ce plugin :
> http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation
>
> Mais je ne sais plus s'il ne fait du rapprochement que sur les
> géométries où les tags aussi. Je me rappelle juste que le
> fonctionnement n'est pas facile à comprendre.
>
> Frédéric.
>
>
>
> Le 30/12/2015 10:01, Tony Emery a écrit :
>> Bonjour à tous,
>>
>> Je voulais savoir si l'un d'entre vous a déjà essayer de faire une
>> jointure
>> attributaire dans JOSM entre des données osm et une couche d'info
>> (shape ou
>> autre) afin de mettre à jour les données OSM ?
>>
>> Si oui, comment on fait ? Sinon, comment faites-vous pour faire ce genre
>> d'opération ?
>>
>>
>>
>> -
>> Tony EMERY
>> Administrateur OpenStreetMap.fr
>> Mandataire Grand Sud-Est
>> Géomaticien & chef de projets
>> -- 
>> View this message in context:
>> http://gis.19327.n5.nabble.com/Jointure-attributaire-dans-JOSM-tp5863476.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
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Christian Quest - OpenStreetMap France


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


Re: [Talk-it] confini amministrativi comunali OSM - Istat

2015-12-30 Per discussione Martin Koppenhoefer
2015-12-30 9:44 GMT+01:00 Federico Cortese :

> Il confine amministrativo è una cosa, il fiume o la strada un'altra,




non sempre, al meno al livello globale un fiume o una strada possono essere
la definizione di un confine, e quando si sposta il fiume si sposta anche
il confine. Similmente le coste.
Non conosco la realtà italiana al livello di definizioni di confini, e di
relativa giurisdizione.

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


Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Per discussione Christian Quest


On 30/12/2015 10:43, osm.sanspourr...@spamgourmet.com wrote:
> pour les *old_ref:INSEE*, je serais plus pour des
> old_ref:INSEE:-2016-01-01=
> (millésimons ! ;-))
>
> Pour le *admin_level=9*, je ne vois pas à quoi tu fais référence : je
> trouve (j'ai regardé uniquement dans l'ouest) et je tombe sur des
> communes associées, déléguées..., bref des choses homogènes qui
> existent déjà, les outils existants ne devraient pas avoir des
> comportement inattendus.

Des choses assez récentes, justement liées au grand bazar actuel des
fusions.
Quelques mois en arrière on n'en avait aucune et pour récupérer les
arrondissements municipaux admin_level=9 + ref:INSEE suffisait... là on
récupère plein d'autre choses qui n'ont pas de rapport.


> Tu ne penses pas au niveau ComCom qui n'est pas (plus) un niveau
> administratif et qui n'est pas de niveau 9 ?
> Les exceptions sont les arrondissements municipaux et ils sont bien
> une subdivision des trois communes PLM comme le sont les communes
> déléguées, donc au même niveau. Pas de même nature, d'où l'autre attribut.
>

Je pense mal me faire comprendre... je ne parle pas d'une modélisation
dans l'absolu "ex-nihilo" où oui, admin_level=9 me semblerait adapté. Je
parle d'une utilisation actuelle des données qui va être potentiellement
impactée si on ne prend pas en compte de nouveaux tags, impact qui
serait beaucoup plus limité si on faisait ça sur admin_level=10 qui
n'avait pas l'homogénéité de admin_level=9

> En ajoutant sur les communes devenues déléguées un tag spécifique style :
> *? **admin_type:FR=commune déléguée*
> on a moyen de changer sans problème.
>

Si on connait ce tag... or les scripts et traitement existant ne le
connaissent pas. Il faut les modifier pour qu'ils ne soient pas impactés...

> Ma requête :
> /relation[admin_level=9]({{bbox}})//
> // ); out center;/
>
> *? source=le JO ou l’arrêté préfectoral**
> ***Le JO c'est plutôt mieux, mais pour Audierne il n'était pas sorti
> (maintenant c'est JORFTEXT31690191)
> dep,nouvelle,anciennes,date,population,chflieu,jorf
> 29,Audierne,Audierne|Esquibien,,3839,Audierne,JORFTEXT31690191
>
> *? start_date=2016-01-01 ou end_date ou autre chose**
> *(pour les communes déléguées)
> Comme c'est "seulement" le niveau administratif qui change, ça ma gène
> un peu de mettre un start_date ou un end_date.
> C'est pour cela que je proposais :
> admin_level:-2016-01-01=8
> admin_level:2016-01-01-=9
> (plus un admin_level=8 jusqu'à demain soir et 9 au delà,
> admin_level=8 et
> admin_level:proposed=9 permettent de scripter le changement à minuit)
> Comme ça les outils marchent (admin_level est correct) et on ne perd
> pas l'information.
> Mais comme dit Vincent, ça crée des tags en plus. Ceci dit, ça permet
> d'affiner. Allez, des volontaires pour faire une animation en CSS par
> exemple pour visualiser les changements ? Ça pourrait être parlant
> pour la promotion d'OSM auprès de la PQR ou des voisins de bureau de
> Christian.
>
> Jean-Yvon
>

Mettre la plage temporelle dans le tag, ça les rend fort inutilisables
si ce n'est pas rendu plus générique. J'avais proposé quelque chose du
genre il y a un bout de temps, mais l'allergie ambiante aux données
"historiques" avait eu raison de cette proposition.
Les tags que tu présente me semble une fausse bonne idée.

Quelqu'un a regardé comment c'est géré dans d'autres pays ?

admin_level=9 + disused:admin_level=8 ça pourrait aussi le faire, mais
on n'a pas d'info sur la date de changement.


J'avance sur le script... il prend maintenant en compte les nouvelles
communes déjà présentes.
J'ai aussi continué à compléter le CSV. Vous pouvez faire des pull
requests...

-- 
Christian Quest - OpenStreetMap France

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


Re: [Talk-it] Mappatura linea bus primo tentativo

2015-12-30 Per discussione Cascafico Giovanni
Ciao.
Sembra che il rendering "trasporti" sia già aggiornato. Ad una prima
occhiata [1] sembra a posto. Hai inserito anche le fermate della direzione
opposta (p.es. Luois Ist. Fermi)?

[1] http://www.openstreetmap.org/#map=17/44.64780/10.92064=T

Il giorno 30 dicembre 2015 10:31, Claudio Baraldi <
claudio.baraldi...@gmail.com> ha scritto:

> Sono finalmente riuscito ad inserire la mia prima "linea Bus", più
> precisamente la "Linea 1" di Modena per il momento solo in una direzione e
> devo dire che non è stato facile, chiaramente avevo poche basi e ho dovuto
> studiarmi i percorsi caricati da altri mappatori.
> Prima di iniziare a caricare ho dovuto posizionare le fermate, aggiustare
> alcuni percorsi, capire e inserire alcune corsie preferenziali, ecc.
>
> Prima di caricare ulteriori linee bus mi piacerebbe che qualcuno più
> esperto controllasse il lavoro appena fatto, la relazione è 5794274
>
> Devo dire che trovo notevole difficoltà a gestire il lavoro nel complesso:
> Josm non mi permette di scaricare dal server un'area sufficientemente
> ampia per coprire l'intero percorso per cui sono costretto a lavorare su
> porzioni del percorso e devo sempre ricordarmi di chiudere la relazione e
> salvare tutto (cio caricare nel server), prima di scaricare una nuova
> porzione di territorio altrimenti si creano conflitti e perdo il lavoro
> fatto.
> Ho visto che c'è la possibilità di scaricare l'intera relazione ma sarebbe
> importante riuscire a scaricare anche l'area immediatamente adiacente al
> percorso, mi sembra impossibile che non si riesca a lavorare su un
> territorio più ampio. Una volta io usavo una estensione che si chiamava
> "scarica da mirror" o qualcosa di simile ma non c'è più, un utente in una
> risposta precedente mi ha detto che ora Josm lo fa automaticamente, ma io
> non riesco, dove sbaglio?
>
>
> Grazie
> Baldorider
> (Claudio Baraldi)
>
> ___
> 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-au] GNAF (address) data to be released under open license

2015-12-30 Per discussione Jason Ward
Hi Simon,

Could you note the clause for clarity please? My guess would be 3a4 of [1]
as I'm not across the meaning of that when applied to the downstream osm
licence.  I've read the links below and on a first pass it appears to be
quite a broad licence to use (Specifically 2a 1B & 2a 1B) of [1] so am
curious to know where the barrier lies.

[1] -
https://www.dpmc.gov.au/sites/default/files/files/EULA_open_G-NAF_administrative_boundaries.pdf

[2] -
https://www.dpmc.gov.au/pmc/about-pmc/core-priorities/public-data-branch-within-dpmc/geocoded-national-address-data-be-made-openly-available


Thanks!

On Wed, 30 Dec 2015 at 20:53 Simon Poole  wrote:

>
> I just had a quick look at the licence terms. While the license is based
> on CC by 4.0 (which is own can of worms) it unluckily contains a provision
> prohibiting specific use that makes the data clearly (as in we will never,
> in no circumstances be able to adhere to the terms) unusable for OSM and
> further means it does not meet the definition here
> http://opendefinition.org/od/1.0/en/.
>
> Sorry
>
>
> Simon
>
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


Re: [Talk-it] Armchair mapping natalizio zone bisognose

2015-12-30 Per discussione Cascafico Giovanni
Be'... questo armchair mapping è proprio bellino: con la campagna abruzzese
sembra di mappare un presepio :-) Ho provato solo un task e credo mi
dedicherò agli altri l'anno prossimo.
 Vista la conformazione urbanistica, molte strade rimarranno sul groppone
degli indigeni.

Il giorno 30 dicembre 2015 11:22, girarsi_liste 
ha scritto:

> Il 30/12/2015 11:19, Martin Koppenhoefer ha scritto:
> >
> >
> > sent from a phone
> >
> >> Am 30.12.2015 um 10:40 schrieb girarsi_liste :
> >>
> >> Siamo ancora in tempo? non ho visto date di termine mapping.
> >
> >
> > non finisce mai ;-)
> >
> > ciao,
> > Martin
> >
> > ___
> > Talk-it mailing list
> > Talk-it@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-it
> >
> ok, era perchè è più comodo per sapere chi mappa o no, rispetto al
> "normale".
>
>
> --
> 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


Re: [Talk-de] Semi-OT: Welches GPS fürs Fahrrad?

2015-12-30 Per discussione Lars Schimmer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30.12.2015 09:47, Volker Schmidt wrote:
> Habe selbst keine Erfahrung, aber mich wundert, dass keiner ueber
> Garmin edge Touring und edge 1000 spricht. Beide kommen von Hause
> aus mit vorinstallierter OSM Karte (=Garmin Cycle Map) fuer ganz
> Europa.

Zu teuer, zu wenig Auflösung.

> Volker


MfG,
Lars Schimmer
- -- 
- -
TU Graz, Institut für ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (MingW32)

iEYEARECAAYFAlaDxB4ACgkQmWhuE0qbFyP+9gCeKwK+5gnZfFHvcksQiWwdMZUw
oN4AnA6rUE/GbqbPXtX4wbw6v4rMfVh0
=+4fr
-END PGP SIGNATURE-

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


Re: [talk-au] GNAF (address) data to be released under open license

2015-12-30 Per discussione Jason Ward
Understood.  For clarity that restriction means the Rights granted in odbl
Clause 3.1 [1] are not possible with this data.

I can understand the restriction so I wonder if there is any scope for this
to be removed.

I do wonder though, when does Licenced Data become Adapted Material?  I ask
as the restriction applies to Licenced Data only.  Probably a question for
the Commonwealth solicitors that wrote the EULA.

[1] - http://opendatacommons.org/licenses/odbl/1.0/


On Wed, 30 Dec 2015 at 21:39 Simon Poole  wrote:

> 2a2
>
>
> Am 30.12.2015 um 12:32 schrieb Jason Ward:
>
> Hi Simon,
>
> Could you note the clause for clarity please? My guess would be 3a4 of [1]
> as I'm not across the meaning of that when applied to the downstream osm
> licence.  I've read the links below and on a first pass it appears to be
> quite a broad licence to use (Specifically 2a 1B & 2a 1B) of [1] so am
> curious to know where the barrier lies.
>
> [1] -
> https://www.dpmc.gov.au/sites/default/files/files/EULA_open_G-NAF_administrative_boundaries.pdf
>
> [2] -
> https://www.dpmc.gov.au/pmc/about-pmc/core-priorities/public-data-branch-within-dpmc/geocoded-national-address-data-be-made-openly-available
>
>
> Thanks!
>
> On Wed, 30 Dec 2015 at 20:53 Simon Poole < si...@poole.ch>
> wrote:
>
>>
>> I just had a quick look at the licence terms. While the license is based
>> on CC by 4.0 (which is own can of worms) it unluckily contains a provision
>> prohibiting specific use that makes the data clearly (as in we will never,
>> in no circumstances be able to adhere to the terms) unusable for OSM and
>> further means it does not meet the definition here
>> http://opendefinition.org/od/1.0/en/.
>>
>> Sorry
>>
>>
>> Simon
>>
>>
>>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Per discussione Philippe Verdy
L'analyse spécifique des tags est moins compliquée que de savoir quels tags
chercher pour trouver les objets. Maintenant dans les deux cas tu auras du
traitement spécifique. C'est une limite d'osm qui ne permet toujours pas
des valeurs structurée et de vrais schémas d'analyse. Il est limite au
couple clé valeur avec une recherche exacte sur la clé. Hors ta proposition
implique de toute façon une clé spécifique pour chaque date. On ne trouvera
donc cette clé que si on a trouve l'objet dans une liste sans regarder
cette clé et charge tous les tags de l'objet pour savoir si on le prend ou
pas.
Je ne vois de toute façon aucune bonne solution.
Le 30 déc. 2015 11:32,  a écrit :

> - parce que ce n'est pas un schéma conseillé
> - parce que tu es obligé d'analyser de manière spécifique ces tags
> - parce que les outils existants ne marcheront pas
> - parce que la tendance est à avoir des attributs spécifiques et non des
> valeurs à rallonge. Ça s'analyse mieux.
> - parce que lire des dates ISO, ce n'est déjà pas évident, alors des dates
> imbriquées dans des tags style admin_level=8 (-2016-01-01);9(2016-01-01-)...
> C'est comme les heures d'ouverture, sans un programme spécifique c'est
> inutilisable sauf que les heures d'ouvertures sont soit ignorées soit
> gérées. Le faire sur le code INSEE passe encore mais sur des données qui
> sont utilisées pour la visualisation des couches classiques...
>
> Ma proposition suit un des schémas de cycle de vie proposés.
>
>
> Le 30/12/2015 11:09, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Pour les old_ref, plutôt que d'ajouter un suffixe de date pourquoi ne pas
> mettre la date ou l'intervalle de dates entre parenthèses après la
> référence, avec en plus la possibilités de plusieurs refs anciennes
> séparées par point-virgule avec chacune la mention de dates? Un seul tag
> alors...
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [talk-au] GNAF (address) data to be released under open license

2015-12-30 Per discussione Simon Poole

I just had a quick look at the licence terms. While the license is based
on CC by 4.0 (which is own can of worms) it unluckily contains a
provision prohibiting specific use that makes the data clearly (as in we
will never, in no circumstances be able to adhere to the terms) unusable
for OSM and further means it does not meet the definition here
http://opendefinition.org/od/1.0/en/. 

Sorry

Simon

Am 07.12.2015 um 03:50 schrieb Daniel O'Connor:
> Hi all,
> Many of you may be interested in 
> https://blog.data.gov.au/news-media/blog/geocoded-national-address-data-be-made-openly-available
>
> Provided the license is CC-BY-3.0 or better; we already have explicit
> permission to use said data:
>
> http://wiki.openstreetmap.org/wiki/Attribution/data.gov.au_explicit_permission
>
> For those of you interested in what specific data this is, I'd
> encourage you to have a read of:
> https://www.psma.com.au/sites/default/files/g-naf_product_description.pdf
>
> Of interest to us:
>  * Address points with geocoding and full structured address information
>  * Authoritive street names for a given suburb, with geocoding (points
> though, not polylines)
>  * Authoritative suburb/locality points, geocoded - likely of better
> accuracy than ABS "Statistic Suburb" data.
>  * Data refreshed quarterly; sourced from local and state government
> (so emailing your council to submit a data correction from survey is
> plausible)
>
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au



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


Re: [talk-au] GNAF (address) data to be released under open license

2015-12-30 Per discussione Simon Poole
2a2

Am 30.12.2015 um 12:32 schrieb Jason Ward:
> Hi Simon,
>
> Could you note the clause for clarity please? My guess would be 3a4 of
> [1] as I'm not across the meaning of that when applied to the
> downstream osm licence.  I've read the links below and on a first pass
> it appears to be quite a broad licence to use (Specifically 2a 1B & 2a
> 1B) of [1] so am curious to know where the barrier lies.
>
> [1]
> - 
> https://www.dpmc.gov.au/sites/default/files/files/EULA_open_G-NAF_administrative_boundaries.pdf
>  
> [2]
> - 
> https://www.dpmc.gov.au/pmc/about-pmc/core-priorities/public-data-branch-within-dpmc/geocoded-national-address-data-be-made-openly-available
>
>
> Thanks!
>
> On Wed, 30 Dec 2015 at 20:53 Simon Poole  > wrote:
>
>
> I just had a quick look at the licence terms. While the license is
> based on CC by 4.0 (which is own can of worms) it unluckily
> contains a provision prohibiting specific use that makes the data
> clearly (as in we will never, in no circumstances be able to
> adhere to the terms) unusable for OSM and further means it does
> not meet the definition here http://opendefinition.org/od/1.0/en/. 
>
> Sorry
>
>
> Simon
>
>>



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


Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Per discussione Tyndare

Sur tous les exemples que j'ai vu le tag ref:INSEE était indiqué sur le nœud 
place, (admin_center)
Si le noeud place correspond au panneau 
du village et non a la commune le tag ref:INSEE n'a pas de sens ici, il 
faudrait le déplacer systématiquement sur la relation admin (pour toutes les 
communes de France)

Je suis mitigé pour basculer les codes INSEE historiques en old_ref
Même si il ne sont plus actifs ils restent toujours plus ou moins valides.





Le 30 décembre 2015 08:05:15 GMT+01:00, "Vincent de Château-Thierry" 
 a écrit :

>Un point qui reste à fixer est le devenir du tag ref:INSEE des communes
>
>déléguées :
>- est-ce qu'elles gardent le tag ref:INSEE sur leur relation admin ?
>ou
>- est-ce qu'on change plutôt ce tag en old_ref:INSEE ? (Rigolez-pas
>dans 
>le fond, on en a déjà ! 
>http://taginfo.openstreetmap.org/keys/old_ref%3AINSEE :) )
>
>vincent



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


Re: [Talk-it] confini amministrativi comunali OSM - Istat

2015-12-30 Per discussione Federico Cortese
2015-12-30 8:59 GMT+01:00 Martin Koppenhoefer :
>
>> Am 29.12.2015 um 15:07 schrieb Stefano :
>>
>> Tiene traccia della storia, non ha problmi con la separazione degli oggetti,
>
> riguardando la separazione e fusione dei oggetti: talvolta un confine è 
> costituito da un fiume o una strada o simile, e in quel caso la topologia 
> corretta per mapparlo in osm sarebbe di avere quel oggetto nella relazione, 
> non solo una copia.
>

Il confine amministrativo è una cosa, il fiume o la strada un'altra,
io sarei per tenere le due cose separate, anche dove il confine segue
l'andamento di altri elementi.

Ciao
Federico

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


Re: [Talk-it] Mappatura linea bus primo tentativo

2015-12-30 Per discussione Claudio Baraldi
Sono finalmente riuscito ad inserire la mia prima "linea Bus", più 
precisamente la "Linea 1" di Modena per il momento solo in una direzione 
e devo dire che non è stato facile, chiaramente avevo poche basi e ho 
dovuto studiarmi i percorsi caricati da altri mappatori.
Prima di iniziare a caricare ho dovuto posizionare le fermate, 
aggiustare alcuni percorsi, capire e inserire alcune corsie 
preferenziali, ecc.


Prima di caricare ulteriori linee bus mi piacerebbe che qualcuno più 
esperto controllasse il lavoro appena fatto, la relazione è 5794274


Devo dire che trovo notevole difficoltà a gestire il lavoro nel complesso:
Josm non mi permette di scaricare dal server un'area sufficientemente 
ampia per coprire l'intero percorso per cui sono costretto a lavorare su 
porzioni del percorso e devo sempre ricordarmi di chiudere la relazione 
e salvare tutto (cio caricare nel server), prima di scaricare una nuova 
porzione di territorio altrimenti si creano conflitti e perdo il lavoro 
fatto.
Ho visto che c'è la possibilità di scaricare l'intera relazione ma 
sarebbe importante riuscire a scaricare anche l'area immediatamente 
adiacente al percorso, mi sembra impossibile che non si riesca a 
lavorare su un territorio più ampio. Una volta io usavo una estensione 
che si chiamava "scarica da mirror" o qualcosa di simile ma non c'è più, 
un utente in una risposta precedente mi ha detto che ora Josm lo fa 
automaticamente, ma io non riesco, dove sbaglio?


Grazie
Baldorider
(Claudio Baraldi)

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


Re: [Talk-cz] Fwd: Vandalismus v důsledku výuky Informatiky u vás na škole

2015-12-30 Per discussione jzvc

Dne 29.12.2015 v 10:17 Jose Riha napsal(a):

moja skusenost s dwg: cca po tyzdni odpoved: porieste si to v ramci
vasej miestnej/narodnej osm komunity. neviem, mozno sa to uz zlepsilo.
proti otvorenosti nic nemam, ale mozno by starsi "kluci" mohli dostat do
ruky nastroj, ktorym by pri vylozene destruktivnych editoch, mali
moznost napriklad zabanovat usera takpovediac okamzite.

On Tue, 29 Dec 2015, Jan Martinec wrote:



Cus, uvedom si, ze jakmile zacnes resit bany, tak musis zacit resit i 
registrace, to ze mi zabanujes ucet, kdyz si obratem muzu regnout jinej 
me v rozletu nijak nebrani, specielne kdyz me zacne bavit, ze te to stve ...


A jak je receno i jinde, osobne to vidim stejne, jakmile mi neco zacne 
hazet klacky pod nohy, tak se na to vykaslu.



Co se wiki tyce, kdopak z vas aspon po ocku sledoval editacni valky na 
ceskem pisecku? Vysledek toho vseho byl defakto predevsim ten, ze se 
spousta i zcela nezucastnenych lidi na jakekoli editace vybodla. 
Jednoduse proto, ze se nehodlali ani potencielne s nejakym trotlem 
dohadovat na tema, jestli tam bude muzeum nebo museum ...


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


Re: [Talk-cz] Tag "network" na pěších turistických trasách

2015-12-30 Per discussione Tom Ka
Delka trasy = delka relace, to je IMHO v pohode. S lwn pro hodne
kratke naprosto souhlasim, klidne at je vetsina rwn.

Dne 30. prosince 2015 9:18 Jan Mladý  napsal(a):
> Reálné využití tagu network vidím v důležitosti/prioritě dané trasy která se 
> dá použít i při vyhodnocení co se má v kterém zoomu vykreslit.
> Viz například 
> http://hiking.waymarkedtrails.org/cs/?zoom=13=50.68018=13.81599=0=0.745#routes
>
> Bohužel ne všechny barvy odpovídají původnímu záměru co je lokální, 
> regionální ... vždy existují výjimky. Vcelku se mi líbí rozdělení podle délky 
> trasy (jak ale vyhodnotit trasy které na sebe navazují, nemění barvu, pouze 
> se mění číslo trasy (a tedy i relace)). Na rozdělení okresů bych se vykašlal 
> a jako lwn bych dal opravdu jenom malé trasy do 5km (ano, pak většina bude 
> rwn).
>
> Honza Mladý alias mkačer
>
> -Original Message-
> From: Tom Ka [mailto:tomas.kaspa...@gmail.com]
> Sent: Wednesday, December 30, 2015 8:32 AM
> To: OpenStreetMap Czech Republic 
> Subject: Re: [Talk-cz] Tag "network" na pěších turistických trasách
>
> Dne 29. prosince 2015 23:12 Václav Kubíček  napsal(a):
>> Také souhlasím s klíčem OTM, jen s jednou menší úpravou, že žlutá by
>> patřila do "rwn" a do "lwn" bych nacpal různé místní a naučné stezky.
>>
>> Podobně to mají Slováci viz
>> http://wiki.openstreetmap.org/wiki/WikiProject_Slovakia/Hiking_routes#
>> Hiking_Routes_Networks_and_Numbering
>
> Koukal jsem, ale prijde mi, ze i podle cisla cesty to KST pomerne striktne 
> dodrzuje, pak to tedy dava smysl i pro "network".
> U KCT viz komentar dole.
>
>>> Rad bych tedy vyvolal nejakou diskusi nad exaktnimi pravidly
>>> oznacovani - tj. podle delky trasy, tim ze prochazi vice nez X okresy
>>> apod. Dovedu si predstavit neco takoveho (vykopavam, rozhodne
>>> netvrdim ze je to idealni nebo final):
>>>
>>> lwn: delka < 10km
>>> rwn: delka > 10km, prochazi min. 2 okresy
>>> nwn: delka > 50km, prochazi min. 2 kraji/3 okresy apod.
>>
>> Možná než se pustíme do téhle diskuse, tak by bylo dobré si ujasnit,
>> proč lwn/rwn/nwn vlastně chceme rozlišovat... má k tomu někdo nějaké
>> stanovisko? Mne by dávalo smysl to mít navázané na to, co za
>> kategorizaci používá správce značek, tedy KČT. Ostatně takhle to
>> děláme i s cyklostrasami.
>>
>> Pročež:
>> Mohl by se někdo, kdo má kontakty do KČT, mohl zeptat, jestli ještě
>> pořád platí logika barev, jak platila dříve a jak byla i ostatně byla
>> navržena pro OpenTrackMap (OTM):
>> červená – dálkové nebo hřebenové trasy modrá – významnější trasy
>> zelená – místní trasy žlutá– krátké trasy, spojovací cesty, zkratky
>> takto je to pořád ještě uvedeno i na Wikipedii:
>> https://cs.wikipedia.org/wiki/Turistick%C3%A9_zna%C4%8Den%C3%AD_v_%C4%
>> 8Cesku_a_na_Slovensku
>>
>> Pokud to KČT považuje za stále platné, tak bych se přikláněl k otmu to
>> nechat podle původního klíče OTM: červená nwn, modrá/zelená rwn, žlutá
>> lwn.
>
> Podle meho nazoru a podle map to je asi porad platne pravidlo, ktere ale neni 
> striktni ale spise zakladni doporuceni. Cast tras tak bude odpovidat, ale 
> najdou se i takove, ktere pujdou proti. Za mne je tedy zakladni otazka, 
> jestli tak "network" bude jen automaticky kopirovat jiny atribut (treba prave 
> barvu) nebo bude definovan nezavisle - prave treba delkou trasy nebo poctem 
> kraju/okresu apod. Za mne prvni varianta nedava moc smysl, resp. je to cisty 
> duplikat a muze to doplnovat a opravovat/kontrolovat automat. Pro mappery je 
> to pak nezajimave.
>
> Proto jsem se ptal i na realne vyuziti, protoze podle toho by se dalo lepe 
> rozhodnout, jak s tim nalozit a k cemu je to dobre.
>
> Bye
>
> ___
> 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-it] Fwd: [OSM-dev] OSM Vector Tiles

2015-12-30 Per discussione Maurizio Napolitano
> Io anche vorrei farlo tra di noi e sono ben disposto ad aiutare, ma
> solo se non utilizziamo mapbox studio (software proprietario) e si
> crea utilizzando cartocss

e se volessi usare mapcss? :)
Scherzi a parte, ribadisco il mio "spot" a provare kismitk
https://github.com/kosmtik/kosmtik
che nasce proprio come alternativa a mapbox studio

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


Re: [Talk-cz] Tag "network" na pěších turistických trasách

2015-12-30 Per discussione Jan Mladý
Délka trasy = relace ... no nevím. To jsou asi ty výjimky.
Hřebenová cesta Krušných Hor (Tisá-Boží Dar) se skládá z několika na sobě 
navazujících úseků (ref 304;314;315 ...) Vše je jedna červená TZ, mění se pouze 
ref. Spojit tedy jednotlivé ref do jedné relace? Asi ne.



-Original Message-
From: Tom Ka [mailto:tomas.kaspa...@gmail.com] 
Sent: Wednesday, December 30, 2015 10:43 AM
To: OpenStreetMap Czech Republic 
Subject: Re: [Talk-cz] Tag "network" na pěších turistických trasách

Delka trasy = delka relace, to je IMHO v pohode. S lwn pro hodne kratke 
naprosto souhlasim, klidne at je vetsina rwn.

Dne 30. prosince 2015 9:18 Jan Mladý  napsal(a):
> Reálné využití tagu network vidím v důležitosti/prioritě dané trasy která se 
> dá použít i při vyhodnocení co se má v kterém zoomu vykreslit.
> Viz například 
> http://hiking.waymarkedtrails.org/cs/?zoom=13=50.68018=13.8159
> 9=0=0.745#routes
>
> Bohužel ne všechny barvy odpovídají původnímu záměru co je lokální, 
> regionální ... vždy existují výjimky. Vcelku se mi líbí rozdělení podle délky 
> trasy (jak ale vyhodnotit trasy které na sebe navazují, nemění barvu, pouze 
> se mění číslo trasy (a tedy i relace)). Na rozdělení okresů bych se vykašlal 
> a jako lwn bych dal opravdu jenom malé trasy do 5km (ano, pak většina bude 
> rwn).
>
> Honza Mladý alias mkačer
>
> -Original Message-
> From: Tom Ka [mailto:tomas.kaspa...@gmail.com]
> Sent: Wednesday, December 30, 2015 8:32 AM
> To: OpenStreetMap Czech Republic 
> Subject: Re: [Talk-cz] Tag "network" na pěších turistických trasách
>
> Dne 29. prosince 2015 23:12 Václav Kubíček  napsal(a):
>> Také souhlasím s klíčem OTM, jen s jednou menší úpravou, že žlutá by 
>> patřila do "rwn" a do "lwn" bych nacpal různé místní a naučné stezky.
>>
>> Podobně to mají Slováci viz
>> http://wiki.openstreetmap.org/wiki/WikiProject_Slovakia/Hiking_routes
>> #
>> Hiking_Routes_Networks_and_Numbering
>
> Koukal jsem, ale prijde mi, ze i podle cisla cesty to KST pomerne striktne 
> dodrzuje, pak to tedy dava smysl i pro "network".
> U KCT viz komentar dole.
>
>>> Rad bych tedy vyvolal nejakou diskusi nad exaktnimi pravidly 
>>> oznacovani - tj. podle delky trasy, tim ze prochazi vice nez X 
>>> okresy apod. Dovedu si predstavit neco takoveho (vykopavam, rozhodne 
>>> netvrdim ze je to idealni nebo final):
>>>
>>> lwn: delka < 10km
>>> rwn: delka > 10km, prochazi min. 2 okresy
>>> nwn: delka > 50km, prochazi min. 2 kraji/3 okresy apod.
>>
>> Možná než se pustíme do téhle diskuse, tak by bylo dobré si ujasnit, 
>> proč lwn/rwn/nwn vlastně chceme rozlišovat... má k tomu někdo nějaké 
>> stanovisko? Mne by dávalo smysl to mít navázané na to, co za 
>> kategorizaci používá správce značek, tedy KČT. Ostatně takhle to 
>> děláme i s cyklostrasami.
>>
>> Pročež:
>> Mohl by se někdo, kdo má kontakty do KČT, mohl zeptat, jestli ještě 
>> pořád platí logika barev, jak platila dříve a jak byla i ostatně byla 
>> navržena pro OpenTrackMap (OTM):
>> červená – dálkové nebo hřebenové trasy modrá – významnější trasy 
>> zelená – místní trasy žlutá– krátké trasy, spojovací cesty, zkratky 
>> takto je to pořád ještě uvedeno i na Wikipedii:
>> https://cs.wikipedia.org/wiki/Turistick%C3%A9_zna%C4%8Den%C3%AD_v_%C4
>> %
>> 8Cesku_a_na_Slovensku
>>
>> Pokud to KČT považuje za stále platné, tak bych se přikláněl k otmu 
>> to nechat podle původního klíče OTM: červená nwn, modrá/zelená rwn, 
>> žlutá lwn.
>
> Podle meho nazoru a podle map to je asi porad platne pravidlo, ktere ale neni 
> striktni ale spise zakladni doporuceni. Cast tras tak bude odpovidat, ale 
> najdou se i takove, ktere pujdou proti. Za mne je tedy zakladni otazka, 
> jestli tak "network" bude jen automaticky kopirovat jiny atribut (treba prave 
> barvu) nebo bude definovan nezavisle - prave treba delkou trasy nebo poctem 
> kraju/okresu apod. Za mne prvni varianta nedava moc smysl, resp. je to cisty 
> duplikat a muze to doplnovat a opravovat/kontrolovat automat. Pro mappery je 
> to pak nezajimave.
>
> Proto jsem se ptal i na realne vyuziti, protoze podle toho by se dalo lepe 
> rozhodnout, jak s tim nalozit a k cemu je to dobre.
>
> Bye
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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


Re: [Talk-it] Fwd: [OSM-dev] OSM Vector Tiles

2015-12-30 Per discussione Luca Delucchi
2015-12-30 11:02 GMT+01:00 Maurizio Napolitano :
>> Io anche vorrei farlo tra di noi e sono ben disposto ad aiutare, ma
>> solo se non utilizziamo mapbox studio (software proprietario) e si
>> crea utilizzando cartocss
>
> e se volessi usare mapcss? :)

non posso aiutare perchè non ho tempo di imparare un altro linguaggio ;-)

> Scherzi a parte, ribadisco il mio "spot" a provare kismitk
> https://github.com/kosmtik/kosmtik
> che nasce proprio come alternativa a mapbox studio
>

che io sappia kosmtik non è in grado di vestire i dati ma solo fare il
rendering di progetti cartocss già esistenti.
Io per ora continuo ad utilizzare tilemill che funziona
tranquillamente con le ultime versioni di mapnik


-- 
ciao
Luca

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

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


Re: [Talk-cz] Tag "network" na pěších turistických trasách

2015-12-30 Per discussione Tom Ka
Tohle ale asi neni bezne nebo ano? Pokud jsou to jednotky vyjimek, tak
se to muze osetrit polo/rucne.

Na zaklade ceho jsi usoudil, ze je to jedna cervena a ne nekolik
ruznych cervenych? (to neni rypani, ale snazim se vytahnout nejake
podklady proc to tak je - min. vnimano). Ciste prakticky by znacka
mela byt na obou koncich ukoncena ctvereckovou znackou zacatek/konec
turisticke trasy, casto to tak asi je, ale urcite to casto bude proste
vynechano. Pak se lze orientovat podle rozcestniku, ale kdyz se znacka
deli na dve, tak je to ta stejna, nebo dve nove se stejnou barvou...


Dne 30. prosince 2015 11:07 Jan Mladý  napsal(a):
> Délka trasy = relace ... no nevím. To jsou asi ty výjimky.
> Hřebenová cesta Krušných Hor (Tisá-Boží Dar) se skládá z několika na sobě 
> navazujících úseků (ref 304;314;315 ...) Vše je jedna červená TZ, mění se 
> pouze ref. Spojit tedy jednotlivé ref do jedné relace? Asi ne.
>
>
>
> -Original Message-
> From: Tom Ka [mailto:tomas.kaspa...@gmail.com]
> Sent: Wednesday, December 30, 2015 10:43 AM
> To: OpenStreetMap Czech Republic 
> Subject: Re: [Talk-cz] Tag "network" na pěších turistických trasách
>
> Delka trasy = delka relace, to je IMHO v pohode. S lwn pro hodne kratke 
> naprosto souhlasim, klidne at je vetsina rwn.
>
> Dne 30. prosince 2015 9:18 Jan Mladý  napsal(a):
>> Reálné využití tagu network vidím v důležitosti/prioritě dané trasy která se 
>> dá použít i při vyhodnocení co se má v kterém zoomu vykreslit.
>> Viz například
>> http://hiking.waymarkedtrails.org/cs/?zoom=13=50.68018=13.8159
>> 9=0=0.745#routes
>>
>> Bohužel ne všechny barvy odpovídají původnímu záměru co je lokální, 
>> regionální ... vždy existují výjimky. Vcelku se mi líbí rozdělení podle 
>> délky trasy (jak ale vyhodnotit trasy které na sebe navazují, nemění barvu, 
>> pouze se mění číslo trasy (a tedy i relace)). Na rozdělení okresů bych se 
>> vykašlal a jako lwn bych dal opravdu jenom malé trasy do 5km (ano, pak 
>> většina bude rwn).
>>
>> Honza Mladý alias mkačer
>>
>> -Original Message-
>> From: Tom Ka [mailto:tomas.kaspa...@gmail.com]
>> Sent: Wednesday, December 30, 2015 8:32 AM
>> To: OpenStreetMap Czech Republic 
>> Subject: Re: [Talk-cz] Tag "network" na pěších turistických trasách
>>
>> Dne 29. prosince 2015 23:12 Václav Kubíček  napsal(a):
>>> Také souhlasím s klíčem OTM, jen s jednou menší úpravou, že žlutá by
>>> patřila do "rwn" a do "lwn" bych nacpal různé místní a naučné stezky.
>>>
>>> Podobně to mají Slováci viz
>>> http://wiki.openstreetmap.org/wiki/WikiProject_Slovakia/Hiking_routes
>>> #
>>> Hiking_Routes_Networks_and_Numbering
>>
>> Koukal jsem, ale prijde mi, ze i podle cisla cesty to KST pomerne striktne 
>> dodrzuje, pak to tedy dava smysl i pro "network".
>> U KCT viz komentar dole.
>>
 Rad bych tedy vyvolal nejakou diskusi nad exaktnimi pravidly
 oznacovani - tj. podle delky trasy, tim ze prochazi vice nez X
 okresy apod. Dovedu si predstavit neco takoveho (vykopavam, rozhodne
 netvrdim ze je to idealni nebo final):

 lwn: delka < 10km
 rwn: delka > 10km, prochazi min. 2 okresy
 nwn: delka > 50km, prochazi min. 2 kraji/3 okresy apod.
>>>
>>> Možná než se pustíme do téhle diskuse, tak by bylo dobré si ujasnit,
>>> proč lwn/rwn/nwn vlastně chceme rozlišovat... má k tomu někdo nějaké
>>> stanovisko? Mne by dávalo smysl to mít navázané na to, co za
>>> kategorizaci používá správce značek, tedy KČT. Ostatně takhle to
>>> děláme i s cyklostrasami.
>>>
>>> Pročež:
>>> Mohl by se někdo, kdo má kontakty do KČT, mohl zeptat, jestli ještě
>>> pořád platí logika barev, jak platila dříve a jak byla i ostatně byla
>>> navržena pro OpenTrackMap (OTM):
>>> červená – dálkové nebo hřebenové trasy modrá – významnější trasy
>>> zelená – místní trasy žlutá– krátké trasy, spojovací cesty, zkratky
>>> takto je to pořád ještě uvedeno i na Wikipedii:
>>> https://cs.wikipedia.org/wiki/Turistick%C3%A9_zna%C4%8Den%C3%AD_v_%C4
>>> %
>>> 8Cesku_a_na_Slovensku
>>>
>>> Pokud to KČT považuje za stále platné, tak bych se přikláněl k otmu
>>> to nechat podle původního klíče OTM: červená nwn, modrá/zelená rwn,
>>> žlutá lwn.
>>
>> Podle meho nazoru a podle map to je asi porad platne pravidlo, ktere ale 
>> neni striktni ale spise zakladni doporuceni. Cast tras tak bude odpovidat, 
>> ale najdou se i takove, ktere pujdou proti. Za mne je tedy zakladni otazka, 
>> jestli tak "network" bude jen automaticky kopirovat jiny atribut (treba 
>> prave barvu) nebo bude definovan nezavisle - prave treba delkou trasy nebo 
>> poctem kraju/okresu apod. Za mne prvni varianta nedava moc smysl, resp. je 
>> to cisty duplikat a muze to doplnovat a opravovat/kontrolovat automat. Pro 
>> mappery je to pak nezajimave.
>>
>> Proto jsem se ptal i na realne vyuziti, protoze podle toho by se dalo lepe 
>> rozhodnout, jak s tim nalozit a k cemu je to dobre.
>>
>> Bye
>>
>> 

Re: [Talk-it] Fwd: [OSM-dev] OSM Vector Tiles

2015-12-30 Per discussione Andrea Albani
No, erroraccio applicativo che puoi vedere ad esempio qui

http://www.gfoss.it/osm/tilecache/tilecache.cgi?LAYERS=osm=image%2Fpng=WMS=1.1.1=GetMap==EPSG%3A900913=1237678.22178,5792266.91198,1238229.43676,5792818.12696=256=256
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] confini amministrativi comunali OSM - Istat

2015-12-30 Per discussione Martin Koppenhoefer


sent from a phone

> Am 29.12.2015 um 15:07 schrieb Stefano :
> 
> Tiene traccia della storia, non ha problmi con la separazione degli oggetti,


riguardando la separazione e fusione dei oggetti: talvolta un confine è 
costituito da un fiume o una strada o simile, e in quel caso la topologia 
corretta per mapparlo in osm sarebbe di avere quel oggetto nella relazione, non 
solo una copia.

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


Re: [OSM-talk-fr] Trouver le bati manquant

2015-12-30 Per discussione Etienne Trimaille
Le 30 décembre 2015 à 09:45, Tony Emery  a écrit :

> J'ai pourtant bien mis comme url
> tms[99]:
> https://api.mapbox.com/v4/pratikyadav.93f1df6f/{zoom}/{x}/{y}.png?access_token=pk.eyJ1IjoicHJhdGlreWFkYXYiLCJhIjoiMTA2YWUxNjRkNmFmZGQ4YzAxZWFiNDk0NDM1YjE1YjAifQ.4P6N5dNmA_WQXd3BsJvu5w
>

En mettant ça comme URL, tu dois avoir tms[99] en double dans l'URL finale
(point numéro 3). Supprime en un.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Trouver le bati manquant

2015-12-30 Per discussione Tony Emery
J'avais vu cette erreur et je l'ai supprimé. Mais c'est pas ça.

Normalement, dans JOSM, la ligne passe en vert quand c'est bon. Et bien là,
elle reste blanche...



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Trouver-le-bati-manquant-tp5863259p5863477.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-cz] zobrazení turististických stezek ve výřezu na old.openstreetmap.cz

2015-12-30 Per discussione Marián Kyral
Dne 19.11.2015 v 14:39 Zdeněk Pražák napsal(a):
> Když na old.openstreetmap.cz kliknu na tlačítko Zobraz turistické
> stezky ve výřezu tak se mi objeví hláška errorLoadingGML

Potvrzuji, že problém buď stále trvá, nebo se znova objevil ;-)
Marián

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


Re: [Talk-it] Fwd: [OSM-dev] OSM Vector Tiles

2015-12-30 Per discussione Luca Delucchi
2015-12-29 16:45 GMT+01:00 Fabrizio Tambussa :
>
>
> Io partecipo volenteri, ma senza nulla togliere all'ottimo lavoro di Marco
> Barbieri, mi piacerebbe fare un qualcosa di nostro, creato dalla comunità.

Io anche vorrei farlo tra di noi e sono ben disposto ad aiutare, ma
solo se non utilizziamo mapbox studio (software proprietario) e si
crea utilizzando cartocss

> Se poi siamo i soliti due, eccoti 5 euro x Marco...
>

Io da buon genovese non ci penso neanche ;-)

> Saluti
>

-- 
ciao
Luca

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

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


Re: [Talk-it] Armchair mapping natalizio zone bisognose

2015-12-30 Per discussione girarsi_liste
Il 27/12/2015 18:54, Fabrizio Tambussa ha scritto:
> Ho appena pubblicato sul sito del task manager:
> http://osmit-tm.wmflabs.org/
> due task di mappatura da remoto per alcune zone bisognose di strade nelle
> regioni Abruzzo e Campania.
> Le zone segnalate in rosso sono quelle piu' carenti di strade: potete
> intervenire con le consuete modalita' utilizzando lo sfondo di immagini
> satellitari usuali (Bing e PCN).
> Lascio comunque tutta la regione riquadrata nel caso qualcuno volesse fare
> controlli sul territorio, cosicchè possa segnalare a tutti il suo passaggio.
> 
> Mappy new year
> Saluti
> 
> Sbiribizio

Siamo ancora in tempo? non ho visto date di termine mapping.



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



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


Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

2015-12-30 Per discussione osm . sanspourriel

pour les *old_ref:INSEE*, je serais plus pour des old_ref:INSEE:-2016-01-01=
(millésimons ! ;-))

Pour le *admin_level=9*, je ne vois pas à quoi tu fais référence : je 
trouve (j'ai regardé uniquement dans l'ouest) et je tombe sur des 
communes associées, déléguées..., bref des choses homogènes qui existent 
déjà, les outils existants ne devraient pas avoir des comportement 
inattendus.
Tu ne penses pas au niveau ComCom qui n'est pas (plus) un niveau 
administratif et qui n'est pas de niveau 9 ?
Les exceptions sont les arrondissements municipaux et ils sont bien une 
subdivision des trois communes PLM comme le sont les communes déléguées, 
donc au même niveau. Pas de même nature, d'où l'autre attribut.


En ajoutant sur les communes devenues déléguées un tag spécifique style :
*? **admin_type:FR=commune déléguée*
on a moyen de changer sans problème.

Ma requête :
/relation[admin_level=9]({{bbox}})//
// ); out center;/

*? source=le JO ou l’arrêté préfectoral**
***Le JO c'est plutôt mieux, mais pour Audierne il n'était pas sorti 
(maintenant c'est JORFTEXT31690191)


dep,nouvelle,anciennes,date,population,chflieu,jorf
29,Audierne,Audierne|Esquibien,,3839,Audierne,JORFTEXT31690191


*? start_date=2016-01-01 ou end_date ou autre chose**
*(pour les communes déléguées)
Comme c'est "seulement" le niveau administratif qui change, ça ma gène 
un peu de mettre un start_date ou un end_date.

C'est pour cela que je proposais :
admin_level:-2016-01-01=8
admin_level:2016-01-01-=9
(plus un admin_level=8 jusqu'à demain soir et 9 au delà,
admin_level=8 et
admin_level:proposed=9 permettent de scripter le changement à minuit)
Comme ça les outils marchent (admin_level est correct) et on ne perd pas 
l'information.
Mais comme dit Vincent, ça crée des tags en plus. Ceci dit, ça permet 
d'affiner. Allez, des volontaires pour faire une animation en CSS par 
exemple pour visualiser les changements ? Ça pourrait être parlant pour 
la promotion d'OSM auprès de la PQR ou des voisins de bureau de Christian.


Jean-Yvon


Le 30/12/2015 08:23, Christian Quest - cqu...@openstreetmap.fr a écrit :
Franchement, le admin_level=9 me gène pour la confusion qu'il va créer 
pour les outils l'utilisant déjà actuellement (et il y en a vu que ces 
découpages étaient exhaustifs).


Je ne me battrais pas là dessus, mais ne vous étonnez pas si il y a 
des trucs qui merdent à court terme ici ou là.


Sur le process, je propose de faire ça en deux temps et via le script 
que j'ai écrit:
1) création des nouvelles relations avec admin_level:proposed=8 / 
start_date=2016-01-01

ça laisse un peu de temps pour vérifier...
2) bascule en admin_level=8 et modif des anciennes communes

L'important étant d'avoir le CSV global bien propre. Le script permet 
d'être homogène et ne mobilise plus de temps humain qu'on peut 
remettre à profit sur le contrôle du résultat.



relation commune délégués :
type=boundary
boundary=administrative
name=*
? admin_level=9
? source=le JO ou l’arrêté préfectoral
? admin_type:FR=commune déléguée
? start_date=2016-01-01 ou end_date ou autre chose

il faut bien sur tomber d'accord sur
quel admin_level?
tag spécifique oui(lequel?) ou non?
le truc c'est que le tag spécial commune déléguée peut être facilement 
supprimé plus tard si on décide qu'il est inutile mais plus difficile 
a ajouté quant tous sera fini.



Le 30 décembre 2015 à 00:46, Donat ROBAUX > a écrit :


Merci Jérome pour le lien. J'avoue ne même pas avoir pensé à
consulter WP... Ils sont vachement plus à jour que nous. Donc nous
on est carrément à la ramasse. Ils ont fouillé dans tous les RAA
(pas eu le temps de passer partout). Faut dire qu'ils ne sont pas
très pratique à consulter.
Va falloir aller faire du pompage chez WP ;)

Pour info et comme je disais dans un précédent mail: sur
Légifrance, les arrêtés étant publiés par date d'arrêté et non par
publication au JO, j'ai dû remonter jusqu'à la page 7. Des arrêtés
datent de juillet et sont publiés seulement le 29/12/2015. Tu
m'étonnes que l'INSEE ne peut pas être à jour... (re clin d’œil à
Christian dans le cadre de la BAN).

Donat


-- Message transféré --
From: "Jérôme Amagat" >
To: "Discussions sur OSM en français"
>
Cc:
Date: Tue, 29 Dec 2015 20:56:15 +0100
Subject: Re: [OSM-talk-fr] Communes nouvelles - fusion de communes
pour la liste des communes nouvelles la page wikipedia :

https://fr.wikipedia.org/wiki/Projet_de_communes_fran%C3%A7aises_nouvelles_en_2016
basée sur les arrêtés préfectoraux, me semble bien mieux et
plus à jour le JO vu qu'il faut attendre que ces même arrêté
soit publié au JO


___
Talk-fr mailing list
 

  1   2   >