date:20141015

Hi,

A new QGIS plugin exists so as to run an overpass query.

This plugin is QuickOSM which you can find in the QGIS's repository :
- using keys/values with autocompletion
- use an extent of the map canvas or an nominatim area
- use some actions so as to edit in JOSM or open external links like
wikipedia
- save your query
- change the default geographic extent of a saved query
- apply some symbology if possible
- use QuickOSM in complexe models of QGIS Processing : fetching some datas
then reprojecte them for instance
-open a osm file by specifying the OGR file 'osmconf'

There is a little video : https://vimeo.com/108737868

I've developped this project during my internship at 3Liz :
http://www.3liz.com/

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

[OSM-talk] OSMF 2014 election details. Spread the word.

2014-10-15 Thread Richard Weait

Hi all,

The OpenStreetMap Foundation election (2014) is coming up soon.  Some
details are still being ironed out and published.  Please pass this
information along to your local community- and language-lists.  Spread
the word to your favoured social networks.

For starters, please find:

Some dates:
Wednesday, 15 October 2014 at 2359H UTC.  Candidate nominations open. (today)

Thursday, 23 October 2014 at 2359H UTC.  Candidate nominations close

Email Proxy votes to open and close some time between these dates.
Details to follow.

Saturday, 08 November 2014, time TBD. In-person voting at SotM Buenos
Aires, Argentina.

Subject to correction, of course.

Candidacy and candidates:
Note that candidates may self-nominate.
The candidate list.
https://wiki.openstreetmap.org/wiki/Foundation/AGM14/Election_to_Board

I've had questions about candidates and candidacy and have posted my
thoughts here:
http://weait.com/foundation-commitments
http://weait.com/osmf-election-2014
Your questions for current or past board members, and for candidates
are welcome on the lists, IRC and other channels.

Voting:
-dates for email proxy voting are not yet confirmed.  Typically, email
proxy voting begins some time after candidacy closes, and ends hours
or days before the in-person voting begins.
-STV voting will be used for the first time in the OSMF context.
Details will be added to the wiki page on proxy voting.
- Matters for voting in 2014 include the Election to the Board, three
special resolutions, and a vote on membership fees.  Details to
follow.
https://wiki.openstreetmap.org/wiki/Foundation/AGM14/Proxy_Voting

Best Regards and Happy Mapping,
Richard

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

[OSM-talk] Your chance to host State of the Map 2015

2014-10-15 Thread Rob Nickerson

Hi list members,

State of the Map conferences are a great way to bring the community
together, reach out to new members and promote innovation. I am delighted
to see that the OpenStreetMap Foundation have committed to continuing State
of the Map in 2015.

The OSMF annual SOTM complements local SOTMs {EU, US, Scotland, etc} and to
me one of the big benefits is that the Foundation remains committed to
taking SOTM to new places. Now it's your chance to host :-)

The call for locations for SOTM 2015 is now open:

http://wiki.openstreetmap.org/wiki/State_Of_The_Map_2015/Call_for_venues

So why are you still reading this, get bidding :-)

Regards,
Rob
SotM 2013 (Birmingham) local team
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] QuickOSM, a QGIS plugin to query Overpass

2014-10-15 Thread Emir Hartato

Hi Etienne,

I've been playing around with the plugin and it looks great!
One question, how often the data is getting updated from OSM server?
Do you have a github page where I can submit issues and suggestion?

Many thanks


*Kind Regards,Emir Hartato*

On Thu, Oct 16, 2014 at 12:08 AM, Etienne Trimaille 
etienne.trimai...@gmail.com wrote:

 Hi,

 A new QGIS plugin exists so as to run an overpass query.

 This plugin is QuickOSM which you can find in the QGIS's repository :
 - using keys/values with autocompletion
 - use an extent of the map canvas or an nominatim area
 - use some actions so as to edit in JOSM or open external links like
 wikipedia
 - save your query
 - change the default geographic extent of a saved query
 - apply some symbology if possible
 - use QuickOSM in complexe models of QGIS Processing : fetching some datas
 then reprojecte them for instance
 -open a osm file by specifying the OGR file 'osmconf'

 There is a little video : https://vimeo.com/108737868

 I've developped this project during my internship at 3Liz :
 http://www.3liz.com/

 Etienne Trimaille

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


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

Re: [OSM-talk] QuickOSM, a QGIS plugin to query Overpass

Thanks for your comment.

2014-10-15 20:15 GMT+02:00 Emir Hartato emir.hart...@gmail.com:

 One question, how often the data is getting updated from OSM server?


It depends of the server you choose.
The main server (overpass-api.de), it's mainly less than 2 minutes.
You can get the timestamp of the server in the parameters of the plugin.


 Do you have a github page where I can submit issues and suggestion?


Yes, tickets are welcome :
https://github.com/3liz/QgisQuickOSMPlugin
But pythonner are welcome too ;-)



 Many thanks


 *Kind Regards,Emir Hartato*

 On Thu, Oct 16, 2014 at 12:08 AM, Etienne Trimaille 
 etienne.trimai...@gmail.com wrote:

 Hi,

 A new QGIS plugin exists so as to run an overpass query.

 This plugin is QuickOSM which you can find in the QGIS's repository :
 - using keys/values with autocompletion
 - use an extent of the map canvas or an nominatim area
 - use some actions so as to edit in JOSM or open external links like
 wikipedia
 - save your query
 - change the default geographic extent of a saved query
 - apply some symbology if possible
 - use QuickOSM in complexe models of QGIS Processing : fetching some
 datas then reprojecte them for instance
 -open a osm file by specifying the OGR file 'osmconf'

 There is a little video : https://vimeo.com/108737868

 I've developped this project during my internship at 3Liz :
 http://www.3liz.com/

 Etienne Trimaille

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



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

Re: [OSM-talk] QuickOSM, a QGIS plugin to query Overpass

2014-10-15 Thread Pierre Béland

Bonjour Étienne
Very interesting and could surely be adapted to work on a website as a 
front-end to Overpass.
I made a query to extract place nodes for a complete Country.
This works nicely with search through Nominatim. Just a little problem 
encountered. The timeout was 25 seconds. Too short for big queries.  Pierre 

  De : Etienne Trimaille etienne.trimai...@gmail.com
 À : Emir Hartato emir.hart...@gmail.com 
Cc : Talk Openstreetmap talk@openstreetmap.org 
 Envoyé le : Mercredi 15 octobre 2014 14h30
 Objet : Re: [OSM-talk] QuickOSM, a QGIS plugin to query Overpass
   
Thanks for your comment.

2014-10-15 20:15 GMT+02:00 Emir Hartato emir.hart...@gmail.com:

One question, how often the data is getting updated from OSM server?

It depends of the server you choose.
The main server (overpass-api.de), it's mainly less than 2 minutes.
You can get the timestamp of the server in the parameters of the plugin.
 
Do you have a github page where I can submit issues and suggestion?

Yes, tickets are welcome :
https://github.com/3liz/QgisQuickOSMPlugin
But pythonner are welcome too ;-) 


 

Many thanks
Kind Regards,
Emir Hartato
On Thu, Oct 16, 2014 at 12:08 AM, Etienne Trimaille 
etienne.trimai...@gmail.com wrote:

Hi,A new QGIS pluginexists so as to run an overpass query.This plugin 
isQuickOSM which you can find in the QGIS's repository :- using keys/valueswith 
autocompletion
- use an extent ofthe map canvas or an nominatim area
- use some actionsso as to edit in JOSM or open external links like wikipedia
- save your query
- change the defaultgeographic extent of a saved query
- apply somesymbology if possible
- use QuickOSM incomplexe models of QGIS Processing : fetching some datas 
thenreprojecte them for instance
-open a osm file byspecifying the OGR file 'osmconf'There is a littlevideo : 
https://vimeo.com/108737868I've developped thisproject during my internship at 
3Liz : http://www.3liz.com/Etienne Trimaille

___
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: [OSM-talk] QuickOSM, a QGIS plugin to query Overpass

Hi Pierre,

QuickOSM is a frontend to Overpass, as OverpassTurbo is another frontend
too but not on the same plateform (qgis vs website).
QuickOSM will improve (in a next version) its communication with
OverpassTurbo like saving a query by getting the short link a query.
And the plugin should be able to read a short link from Overpass Turbo.

There are 2 ways for increasing the timeout :
- you can extend the timeout in the advanced panel (click on it) of the
query, simplest way
- you can click on the button show query to manually edit the XML

2014-10-15 22:42 GMT+02:00 Pierre Béland pierz...@yahoo.fr:

 Bonjour Étienne

 Very interesting and could surely be adapted to work on a website as a
 front-end to Overpass.

 I made a query to extract place nodes for a complete Country.

 This works nicely with search through Nominatim. Just a little problem
 encountered. The timeout was 25 seconds. Too short for big queries.

 Pierre

   --
  *De :* Etienne Trimaille etienne.trimai...@gmail.com
 *À :* Emir Hartato emir.hart...@gmail.com
 *Cc :* Talk Openstreetmap talk@openstreetmap.org
 *Envoyé le :* Mercredi 15 octobre 2014 14h30
 *Objet :* Re: [OSM-talk] QuickOSM, a QGIS plugin to query Overpass

 Thanks for your comment.

 2014-10-15 20:15 GMT+02:00 Emir Hartato emir.hart...@gmail.com:

 One question, how often the data is getting updated from OSM server?


 It depends of the server you choose.
 The main server (overpass-api.de), it's mainly less than 2 minutes.
 You can get the timestamp of the server in the parameters of the plugin.


 Do you have a github page where I can submit issues and suggestion?


 Yes, tickets are welcome :
 https://github.com/3liz/QgisQuickOSMPlugin
 But pythonner are welcome too ;-)






 Many thanks


 *Kind Regards,Emir Hartato*

 On Thu, Oct 16, 2014 at 12:08 AM, Etienne Trimaille 
 etienne.trimai...@gmail.com wrote:

 Hi,
 A new QGIS plugin exists so as to run an overpass query.
 This plugin is QuickOSM which you can find in the QGIS's repository :
 - using keys/values with autocompletion
 - use an extent of the map canvas or an nominatim area
 - use some actions so as to edit in JOSM or open external links like
 wikipedia
 - save your query
 - change the default geographic extent of a saved query
 - apply some symbology if possible
 - use QuickOSM in complexe models of QGIS Processing : fetching some datas
 then reprojecte them for instance
 -open a osm file by specifying the OGR file 'osmconf'
 There is a little video : https://vimeo.com/108737868
 I've developped this project during my internship at 3Liz :
 http://www.3liz.com/
 Etienne Trimaille

 ___
 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

[OSM-talk] Fwd: [Talk-us] Presenting your new OSM-US board

2014-10-15 Thread Martijn van Exel

Hello all,

The US Chapter Board elections were held this past week, and the results
were just announced on talk-us. See Toby Murray's post below.

Martijn

-- Forwarded message --
From: Toby Murray toby.mur...@gmail.com
Date: Wed, Oct 15, 2014 at 4:43 PM
Subject: [Talk-us] Presenting your new OSM-US board
To: talk-us talk...@openstreetmap.org

Voting closed on the OSM-US board election last night. Michael Collinson
and I acted as election observers and we are both satisfied that the
election was carried out properly. So today I am happy to announce our new
board members:

Alyssa Wright
Martijn van Exel
Alex Barth
Ian Dees
Eleanor Tutt

More information and some notes from Michael about the election are up on
the openstreetmap.us blog:
http://openstreetmap.us/2014/10/election-results/

Please join me in thanking the outgoing board members for their service to
the OSM community in the US over the past year and welcome the new members
to the challenges ahead for next year.

Toby

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

-- 
Martijn van Exel
skype: mvexel
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-br] Reunião semanal OSM Brasil

2014-10-15 Thread Thierry Jean

Caros,
 
A reunião, a semana passada até que funcionou bem com o Gotomeeting, mas 
decidimos, por questão de ritmo, que esta reunião poderia acontecer a cada duas 
semanas.
 
Não vai ter reunião hoje, mas teremos a reunião na semana que vem dia 22/10/14 
às 13h.
 
Abs a todos.

Thierry Jean



 
From: thierryaj...@hotmail.com
To: talk-br@openstreetmap.org
Date: Wed, 8 Oct 2014 12:20:37 -0300
Subject: [Talk-br] Reunião semanal OSM Brasil




Caros,
 
Como apanhamos bastante, as ultimas semanas para ter uma comunicação descente, 
eu pegeui emprestada a conta Gotomeeting de uma amigo.
 
Quem estiver no Celular, baixar o aplicativo Gotomeeting e inserir o numero 
do meeting (599-804-118) , que sera aberto hoje a partir de 12h50.
 
Abaixo as instruçoes:
 



1.  Please join my meeting.


https://www3.gotomeeting.com/join/599804118


 2.  You will be connected to
audio using your computer's microphone and speakers (VoIP).  A headset is 
recommended.


 


Meeting ID: 599-804-118



Thierry Jean


 
  

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

[Talk-it] OpenStreetMap al Linux Day

2014-10-15 Thread Daniele Forsi

Buon pomeriggio,

se parlate di OSM al Linux Day, aggiungete la vostra città alla pagina
https://wiki.openstreetmap.org/wiki/WikiProject_Italy/Events

-- 
Daniele Forsi

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

[Talk-it] Fwd: [OSM-talk] Your chance to host State of the Map 2015

2014-10-15 Thread Cristian Consonni

Sono aperte le candidature per ospitare State of the Map nel 2015.

Ciao,

C

-- Forwarded message --
From: Rob Nickerson rob.j.nicker...@gmail.com
Date: 2014-10-15 19:46 GMT+02:00
Subject: [OSM-talk] Your chance to host State of the Map 2015
To: OpenStreetMap t...@openstreetmap.org

Hi list members,

State of the Map conferences are a great way to bring the community
together, reach out to new members and promote innovation. I am
delighted to see that the OpenStreetMap Foundation have committed to
continuing State of the Map in 2015.

The OSMF annual SOTM complements local SOTMs {EU, US, Scotland, etc}
and to me one of the big benefits is that the Foundation remains
committed to taking SOTM to new places. Now it's your chance to host
:-)

The call for locations for SOTM 2015 is now open:

http://wiki.openstreetmap.org/wiki/State_Of_The_Map_2015/Call_for_venues

So why are you still reading this, get bidding :-)

Regards,
Rob
SotM 2013 (Birmingham) local team

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

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

Re: [Talk-it] Fwd: [OSM-talk] Your chance to host State of the Map 2015

2014-10-15 Thread andriatz

ehh! ;)



--
View this message in context: 
http://gis.19327.n5.nabble.com/Fwd-OSM-talk-Your-chance-to-host-State-of-the-Map-2015-tp5820421p5820433.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Fwd: [OSM-talk] Your chance to host State of the Map 2015

2014-10-15 Thread sabas88

Lo facciamo o no?
Ai quattro gatti che c'erano ad OSMit l'ho ripetuto diverse volte.

Ciao,
Stefano
Ps come si dice qua,  non facciamoci mangiare il belino dalle mosche :)
On 15 Oct 2014 21:58, andriatz andreazedd...@gmail.com wrote:

 ehh! ;)



 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Fwd-OSM-talk-Your-chance-to-host-State-of-the-Map-2015-tp5820421p5820433.html
 Sent from the Italy General mailing list archive at Nabble.com.

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

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

[Talk-it] Parte dal Piemonte il contest su mappe create con OpenStreetMap

2014-10-15 Thread Maurizio Napolitano

Copio/incollo da
http://www.cr.piemonte.it/cms/comunicati/2014/ottobre/2544-piemonte-visual-contest.html


Parte a ottobre un concorso aperto a tutti: è il mappathon, la sfida
lanciata a comunità di sviluppatori, data analyst, designer, geografi,
ricercatori per partecipare alla mappatura del Piemonte con
OpenStreetMap su temi di interesse collettivo.
OpenStreetMap è un progetto collaborativo di raccolta e condivisione
di dati geografici aperti: si basa su una comunità di mappatori
volontari, sempre più grande e diffusa in tutto il mondo, che crea
mappe libere, condivise e gratuite.
Ed è questa la filosofia del concorso: i dati geografici rappresentano
un bene comune, accrescere il patrimonio di dati aperti disponibili
aiuta lo sviluppo del territorio, migliora la qualità della vita dei
luoghi in cui viviamo, è un incentivo per la creazione di nuovi
servizi offerti anche da privati.

Organizzatori
Con il mappathon si apre ufficialmente la seconda edizione di Piemonte
Visual Contest, l’appuntamento annuale organizzato dal Consiglio
regionale del Piemonte insieme a Top-Ix e Csi Piemonte, in
collaborazione con il Tavolo Open Data della Direzione Innovazione
della Regione Piemonte.
Da alcuni anni, infatti, il Consiglio ha avviato una serie di
iniziative che coinvolgono realtà pubbliche e private per promuovere
la cultura open, la trasparenza e il coinvolgimento dei cittadini
nelle politiche pubbliche.

Come funziona
Al concorso possono partecipare cittadini, associazioni, comunità,
scuole e aziende dell’Unione Europea. I partecipanti dovranno
realizzare mappe basate su OpenStreetMap che interessino il territorio
piemontese e progetti di utilizzo, ad esempio un  servizio web, un’app
o un prototipo per la produzione di oggetti a tema geografico.
Le regole della competizione prevedono l’utilizzo di dati pubblici
rilasciati da amministrazioni e privati e - conseguentemente - il
rilascio in formato libero, aperto e riutilizzabile attraverso
OpenStreetMap dei dati raccolti direttamente o attinti da fonti
esistenti.
La maggior parte dei dati sono reperibili su dati.piemonte.it, il
portale promosso dalla Regione Piemonte, a disposizione di tutta la PA
piemontese, per la condivisione dei dati e delle informazioni
pubbliche.
I progetti inviati saranno valutati da una giuria di esperti premierà
i primi tre classificati, che riceveranno rispettivamente un premio
dell’ammontare lordo di 4.600, 2.500 e 1.400 euro.

Deadline
Il termine per l’invio dei progetti è il 9 febbraio 2015 (entro le ore 9.00).
La premiazione dei vincitori si terrà a marzo, in occasione
dell’evento #PA140 organizzato dal Consiglio regionale.

Da segnare in agenda
Durante tutto il tempo del concorso saranno organizzati momenti di
formazione e networking per imparare i tool di mappatura, scambiarsi
idee, discutere delle applicazioni possibili con rappresentanti di
amministrazioni locali.

Sono uno sviluppatore, cerco un mappatore…
La pagina Facebook di Piemonte Visual Contest è aperta a tutti per
rimanere aggiornati, confrontarsi e creare gruppi di lavoro.

Partnership
Piemonte Visual Contest si avvale di partnership importanti che
raccolgono le migliori professionalità del digitale italiano, come la
Fondazione Bruno Kessler di Trento, Wikimedia Italia, CSP Innovazione
nell’ICT e Dipartimento Interateneo di Scienze, Progetto e Politiche
del Territorio di Università e Politecnico di Torino.
Ha inoltre sponsor come Talent Garden Torino e Coldiretti Torino e la
media partnership di Nova Il Sole 24 Ore.

Il regolamento del concorso e tutte le notizie utili nel periodo di
elaborazione delle proposte sono disponibili su
www.piemontevisualcontest.eu

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

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

Re: [Talk-it] Fwd: [OSM-talk] Your chance to host State of the Map 2015

2014-10-15 Thread Maurizio Napolitano

On Wed, Oct 15, 2014 at 7:51 PM, Cristian Consonni
kikkocrist...@gmail.com wrote:
 Sono aperte le candidature per ospitare State of the Map nel 2015.

e ci stiamo seriamente pensando :)

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

Re: [Talk-uy] Montevideo. Nomenclator Rossell y bicisendas.

2014-10-15 Thread muralito

Guillermo, gracias por la informacion!

La carteleria vial está con el nombre incorrecto en Alejo Rosell y Rius y 
Rivera, y en toda Dolores Pereira de Rosell, lo vi el fin de semana pasado.

Esperemos por lo de las bicisendas entonces, en los mapas de bici creo que se 
mejoraria mucho el ruteo haciendolas ir por esas calles, aunque en el caso de 
los autos creo que no cambiaria mucho el ruteo, porque realmente no hay 
demasiadas variantes en esa zona.

Saludos,
M.

- Mensaje original -
De: Guillermo Moncecchi gmo...@gmail.com
Para: mural...@montevideo.com.uy
CC: talk-uy talk-uy@openstreetmap.org, montevideoabie...@imm.gub.uy
Enviados: Martes, 14 de Octubre 2014 20:10:13
Asunto: Re: Montevideo. Nomenclator Rossell y bicisendas.

Estimados, respondo:

a) esto es lo que me dijeron en Nomenclatura (la posta en la
Intendencia, digamos), respecto a Dolores...:


Te comento que la calle oficialmente es Dolores Pereira de Rosell, con
 i latina y con una s.

La denominación se regularizó en el Decreto Nº34741 del 01/08/2013 y
Resolución 3664/13 del 19/08/2013.

Antes Dolores Pereira de Rossell estaba registrada con doble S, pero
al considerar que el apellido Rosell era del esposo se le quita la s
de más y queda similar a la denominación Rosell y Rius. Estas
denominaciones datan de noviembre de 1919, Boletín Municipal página
332.
---

b) El relevamiento de bicisendas y demás ya se está haciendo, en
cuanto esté pronto se va a publicar como datos abiertos.

saludos
guillermo

2014-10-13 17:20 GMT-02:00  mural...@montevideo.com.uy:
 Hola tod@s.

 Seria conveniente aclarar como es el nombre correcto para Alejo Rosell y
 Rius y Dolores Pereira de Rossell.
 La pagina de Nomenclator de IMM dice una cosa (
 http://www.montevideo.gub.uy/aplicacion/nomenclator/6033 y
 http://www.montevideo.gub.uy/aplicacion/nomenclator/6168)
 La carteleria vial de Alejo Rosell y Rius esta mezclada, algunos carteles
 aparece on 1 s y otos con 2 s (el de la esquina de Rivera, p. ej.)
 Si se busca en internet aparece direcciones de ambas formas.
 Con Dolores... la carteleria esta con 2 s,  (Pero si Alejo es el esposo no
 seria el mismo apellido?) ademas de la confusion con Perei(i/y)ra?


 Guillermo ¿Tendras posibilidad de aclarar esto?

 Otro tema, tuve la necesitad de andar por la Ciudad Vieja, y vi que hay
 bicisendas por varios lados, sendas exclusivas, calles de 30 km/h, etc.
 No andaba con nada para anotar, y despues no encontre datos en el sitio de
 IMM al respecto.
 ¿Alguien podria relevar esto?

 Gracias.

 Saludos,
 M.



 ---


 Más espacio, más servicios.
 Nuevos planes de hosting de Montevideo COMM.
 http://bit.ly/planeshosting



 ---





-- 
Guillermo Moncecchi

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

Re: [Talk-uy] Montevideo. Nomenclator Rossell y bicisendas.

2014-10-15 Thread muralito

Las que son carril separado estaban mapeadas como tales y en las que comparten 
calzada con los autos estaban las velocidades a 30 km/h (esto deberia 
desalentar que los autos circulen por esas). 
Estas bicisendas con sendas compartidas con autos las acabo de poner como 
cycleway=shared_lane que les estaba faltando, para alentar a los mapas de bici 
a circular por ahi. 

Lamentablemente en la realidad la cosa no funciona tan bien como en los 
papeles. En la bicisenda mas vieja, por Bvar. Artigas estoy aburrido de ver 
autos parados sobre la bicisenda, y gente caminando, y los ciclistas regalados 
andando como si nada por la calzada cuando esta bien cargada en hora pico. 

Saludos, 
M. 


- Mensaje original - 
De: Anibal Pereira anibali...@gmail.com 
Para: mural...@montevideo.com.uy 
Enviados: Martes, 14 de Octubre 2014 22:03:37 
Asunto: Re: [Talk-uy] Montevideo. Nomenclator Rossell y bicisendas. 


Tambien hay bicisendas en Gonzalo Ramirez y Herrera y Reissig 



El 13 de octubre de 2014, 17:20,  mural...@montevideo.com.uy  escribió: 




Hola tod@s. 

Seria conveniente aclarar como es el nombre correcto para Alejo Rosell y Rius 
y Dolores Pereira de Rossell. 
La pagina de Nomenclator de IMM dice una cosa ( 
http://www.montevideo.gub.uy/aplicacion/nomenclator/6033 y 
http://www.montevideo.gub.uy/aplicacion/nomenclator/6168 ) 
La carteleria vial de Alejo Rosell y Rius esta mezclada, algunos carteles 
aparece on 1 s y otos con 2 s (el de la esquina de Rivera, p. ej.) 
Si se busca en internet aparece direcciones de ambas formas. 
Con Dolores... la carteleria esta con 2 s, (Pero si Alejo es el esposo no 
seria el mismo apellido?) ademas de la confusion con Perei(i/y)ra? 


Guillermo ¿Tendras posibilidad de aclarar esto? 

Otro tema, tuve la necesitad de andar por la Ciudad Vieja, y vi que hay 
bicisendas por varios lados, sendas exclusivas, calles de 30 km/h, etc. 
No andaba con nada para anotar, y despues no encontre datos en el sitio de IMM 
al respecto. 
¿Alguien podria relevar esto? 

Gracias. 

Saludos, 
M. 

---


Más espacio, más servicios.
Nuevos planes de hosting de Montevideo COMM. http://bit.ly/planeshosting 
--- 

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


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

[Talk-uy] Propuesta #editathon hispanoamericana

2014-10-15 Thread Marco Antonio

Hola,

Alex Barth aka @lxbarth escribió hace muy poco «Esta es la razón del
porqué hacemos #editathones» en el blog de openstreetmap.us [1].
Importante reflexión y deja recomendaciones (tips) como ser incluir
hashtags #editathon, ayudar a novatos, lugar del evento y
promoción/publicidad.

Terminando la lectura me vino a la cabeza la idea ¿porqué no hacer una
#editathon hispanoamericana? Existen los medios, existe la comunidad
¿porqué no?

El tema logístico se deja a cada comunidad local. Habría que escribir
una página wiki del evento y pedir que cada comunidad por país añada
las ciudades, sus objetivos, lugares de reunión (leer artículo) y
promocionar. Una fecha probable para el evento... este fin de mes 31
de agosto.

¿Qué opinan?

PD: Este correo fue enviado a 14 listas de correos (Argentina,
Bolivia, Chile, Colombia, Costa Rica, Cuba, Ecuador, España, México,
Nicaragua, Perú, República Dominicana, Uruguay y Venezuela) faltando
las comunidades de Belice, El Salvador, Guatemala, Honduras, Panamá,
Paraguay y Puerto Rico. Por el idioma omití Brasil y Portugal. El que
tenga conocimiento de las comunidades en esos países o sepa el idioma
portugués que haga el favor de replicar.

[1] http://openstreetmap.us/2013/07/why-editathons/

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

[Talk-dk] Vejnavne


Der forekommer en del vejnavne, der er stavet som Gl Xvej, Gl. Xvej m.m.
Så vidt jeg har forstået bør disse nu være Gammel Xvej.

Kan det rettes globalt?
Har det været rettet tidligere, men det er resultatet af brugere, der 
har rettet tilbage?


Tilsvarende kan man finde Sct, Skt, Chr, Dr m.m.

mvh
Uffe Kousgaard


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

Re: [Talk-dk] Vejnavne

2014-10-15 Thread Nick Østergaard

Hej Uffe

Sådanne rettelser skal vist rapporteret i http://oisfixes.iola.dk/
således de kan rettes i addresseimporteringskilden OIS/OSAK.

Nick

2014-10-15 9:37 GMT+02:00 Uffe Kousgaard uffe.kousga...@routeware.dk:
 Der forekommer en del vejnavne, der er stavet som Gl Xvej, Gl. Xvej m.m.
 Så vidt jeg har forstået bør disse nu være Gammel Xvej.

 Kan det rettes globalt?
 Har det været rettet tidligere, men det er resultatet af brugere, der har
 rettet tilbage?

 Tilsvarende kan man finde Sct, Skt, Chr, Dr m.m.

 mvh
 Uffe Kousgaard


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

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

Re: [Talk-dk] Vejnavne





Hej,

Det er ikke adresser, men derimod vejenes navne jeg refererer til.
"ways".

Hilsen
Uffe

Nick Østergaard wrote:

  Hej Uffe

Sådanne rettelser skal vist rapporteret i http://oisfixes.iola.dk/
således de kan rettes i addresseimporteringskilden OIS/OSAK.

Nick

2014-10-15 9:37 GMT+02:00 Uffe Kousgaard uffe.kousga...@routeware.dk:
  
  
Der forekommer en del vejnavne, der er stavet som "Gl Xvej", "Gl. Xvej" m.m.
Så vidt jeg har forstået bør disse nu være "Gammel Xvej".

Kan det rettes globalt?
Har det været rettet tidligere, men det er resultatet af brugere, der har
rettet tilbage?

Tilsvarende kan man finde Sct, Skt, Chr, Dr m.m.

mvh
Uffe Kousgaard


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

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




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

Re: [Talk-dk] Vejnavne

2014-10-15 Thread Nick Østergaard

Har du overhoved klikket på linket? Et vejnavn er vel altid et subsæt
af en addresse.

Se også http://wiki.openstreetmap.org/wiki/Vejnavne

15. okt. 2014 kl. 10.23 skrev Uffe Kousgaard uffe.kousga...@routeware.dk:
 Hej,

 Det er ikke adresser, men derimod vejenes navne jeg refererer til. ways.

 Hilsen
 Uffe


 Nick Østergaard wrote:

 Hej Uffe

 Sådanne rettelser skal vist rapporteret i http://oisfixes.iola.dk/
 således de kan rettes i addresseimporteringskilden OIS/OSAK.

 Nick

 2014-10-15 9:37 GMT+02:00 Uffe Kousgaard uffe.kousga...@routeware.dk:


 Der forekommer en del vejnavne, der er stavet som Gl Xvej, Gl. Xvej m.m.
 Så vidt jeg har forstået bør disse nu være Gammel Xvej.

 Kan det rettes globalt?
 Har det været rettet tidligere, men det er resultatet af brugere, der har
 rettet tilbage?

 Tilsvarende kan man finde Sct, Skt, Chr, Dr m.m.

 mvh
 Uffe Kousgaard


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


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



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


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

Re: [Talk-dk] Vejnavne





Det link handler om at rette vejnavnet i adresser via OSAK.

Et vejnavn kan enten indgå i adresser (punktdata) eller i vejens navn
(strækningsdata). Disse behøver ikke matche, men burde gøre det.

Adresser importeres fra OSAK, hvorimod vejenes navne indtastes af
brugerne og derfor kan de nemt være forkerte.

Det er de sidste jeg snakker om.

mvh
Uffe


Nick Østergaard wrote:

  Har du overhoved klikket på linket? Et vejnavn er vel altid et subsæt
af en addresse.

Se også http://wiki.openstreetmap.org/wiki/Vejnavne

15. okt. 2014 kl. 10.23 skrev Uffe Kousgaard uffe.kousga...@routeware.dk:
  
  
Hej,

Det er ikke adresser, men derimod vejenes navne jeg refererer til. "ways".

Hilsen
Uffe


Nick Østergaard wrote:

Hej Uffe

Sådanne rettelser skal vist rapporteret i http://oisfixes.iola.dk/
således de kan rettes i addresseimporteringskilden OIS/OSAK.

Nick

2014-10-15 9:37 GMT+02:00 Uffe Kousgaard uffe.kousga...@routeware.dk:


Der forekommer en del vejnavne, der er stavet som "Gl Xvej", "Gl. Xvej" m.m.
Så vidt jeg har forstået bør disse nu være "Gammel Xvej".

Kan det rettes globalt?
Har det været rettet tidligere, men det er resultatet af brugere, der har
rettet tilbage?

Tilsvarende kan man finde Sct, Skt, Chr, Dr m.m.

mvh
Uffe Kousgaard


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


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



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


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




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

Re: [Talk-dk] Vejnavne

2014-10-15 Thread Jørgen Elgaard Larsen

Uffe Kousgaard skrev:
 Der forekommer en del vejnavne, der er stavet som Gl Xvej, Gl. Xvej
 m.m.

Det ville være godt, hvis du kunne give et par eksempler på sådanne
vejnavne - så er det nemmere at forholde sig til.

 Så vidt jeg har forstået bør disse nu være Gammel Xvej.

Det er korrekt.

 Kan det rettes globalt?

Nej. Det kræver vurdering i hvert enkelt tilfælde. Står Gl fx. for
Gammel eller Gamle? Eller værre endnu: Står Dr. for Doktor eller
Dronning?

Et eksempel på, hvor galt en global rettelse kan gå kan findes her:
http://www.microformats.dk/2011/08/09/geografisk-arvesynd/

 Har det været rettet tidligere, men det er resultatet af brugere, der
 har rettet tilbage?

Det er svært at vide uden konkrete eksempler.


Tidligere var der en fin side på http://osm.rasher.dk/tools, hvor man
kunne finde frem til potentielt defekte vejnavne. Men den er
tilsyneladende nede i øjeblikket.

Men i alle tilfælde var der en del vejnavne, hvor det ikke umiddelbart
var muligt at gætte, hvad der var rigtigt uden at besøge stedet. Det kan
være, at du er faldet over nogle af dem.

- Jørgen




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

Re: [Talk-dk] Vejnavne





Her er f.eks. Sct Nicolaj Gade:
http://www.openstreetmap.org/#map=17/56.45251/9.41410
Staves både Sct og Sanct i området.

Men der er mange flere.

Globalt skal selvfølgelig kun forstås som den danske del af OSM.

At der kan være tvivl i enkelte situationer såsom Dr, skal forhåbentlig
ikke være en undskyldning for ikke generelt at rette igennem i alle de
tilfælde, hvor der ikke er nogen tvivl.
Der er i øvrigt kun 2 veje med Dr.
Den ene Dronning Ingrid og den anden Doktor Lassen.

Hilsen
Uffe

Jørgen Elgaard Larsen wrote:

  Uffe Kousgaard skrev:
  
  
Der forekommer en del vejnavne, der er stavet som "Gl Xvej", "Gl. Xvej"
m.m.

  
  
Det ville være godt, hvis du kunne give et par eksempler på sådanne
vejnavne - så er det nemmere at forholde sig til.

  
  
Så vidt jeg har forstået bør disse nu være "Gammel Xvej".

  
  
Det er korrekt.

  
  
Kan det rettes globalt?

  
  
Nej. Det kræver vurdering i hvert enkelt tilfælde. Står "Gl" fx. for
"Gammel" eller "Gamle"? Eller værre endnu: Står "Dr." for "Doktor" eller
"Dronning"?

Et eksempel på, hvor galt en global rettelse kan gå kan findes her:
http://www.microformats.dk/2011/08/09/geografisk-arvesynd/

  
  
Har det været rettet tidligere, men det er resultatet af brugere, der
har rettet tilbage?

  
  
Det er svært at vide uden konkrete eksempler.


Tidligere var der en fin side på http://osm.rasher.dk/tools, hvor man
kunne finde frem til potentielt defekte vejnavne. Men den er
tilsyneladende nede i øjeblikket.

Men i alle tilfælde var der en del vejnavne, hvor det ikke umiddelbart
var muligt at gætte, hvad der var rigtigt uden at besøge stedet. Det kan
være, at du er faldet over nogle af dem.

- Jørgen




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




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

Re: [Talk-dk] Vejnavne

2014-10-15 Thread Jørgen Elgaard Larsen

Uffe Kousgaard skrev:
 Her er f.eks. Sct Nicolaj Gade:
 http://www.openstreetmap.org/#map=17/56.45251/9.41410
 Staves både Sct og Sanct i området.

Den er et eksempel på, at nogen har rettet det tilbage. Du kan selv
checke på følgende måde:


I JOSM:
* Markér vejen og tryk Ctrl+H


På www.openstreetmap.org:
* Til højre på siden klikker du på ikonet Lag
* Sæt hak i feltet Kortdata
* Klik på vejen
* Scroll ned i bunden af feltet til venstre og klik Se historik


Du burde nu ende på siden http://www.openstreetmap.org/way/93973172/history

Her kan du se, at vejen i version #3 hed Sanct Nikolaj Gade, men er
blevet ændret i version #4 af brugeren KortMap.

Samme bruger har på tilsvarende vis været i gang med Sct. Mogensgade
(https://www.openstreetmap.org/way/65553629/history), St. Sct. Hans
Gade (https://www.openstreetmap.org/way/39243464/history) og flere
andre i området.

Det korrekte ville være at rette henvendelse til den pågældende bruger
og bede ham om at rette tilbage, gerne med henvisning til de relevante
wiki-sider.

Hvis han ikke reagerer, kan man rulle de pågældende ændringssæt tilbage.

 At der kan være tvivl i enkelte situationer såsom Dr, skal forhåbentlig
 ikke være en undskyldning for ikke generelt at rette igennem i alle de
 tilfælde, hvor der ikke er nogen tvivl.

Nej, det er klart. Jeg mente bare, at man ikke kan gære det automatisk,
men må vurdere i hvert enkelt tilfælde.

Det er forholdsvis få vejnavne, hvor man ikke kan gætte.

Men i dette tilfælde er der åbenbart tale om en bruger som (antageligvis
i uvidenhed) omgør det ret store arbejde, der blev gjort tidligere for
at rette op på forkortelserne.

Det er lidt irriterende, men det er meget nemmere at få rullet hans
ændringer tilbage end at skulle gennemgå alle vejene selv.


- Jørgen


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

Re: [Talk-dk] Vejnavne

2014-10-15 Thread Niels Elgaard Larsen

On 14-10-15 05:33 AM, Uffe Kousgaard wrote:
 Her er f.eks. Sct Nicolaj Gade:
 http://www.openstreetmap.org/#map=17/56.45251/9.41410
 Staves både Sct og Sanct i området.

 Men der er mange flere.

Og værre.

Jeg blev nødt til at rette Sc.t Ibs Gade og nogle af de andre i området.

 Globalt skal selvfølgelig kun forstås som den danske del af OSM.

 At der kan være tvivl i enkelte situationer såsom Dr, skal
 forhåbentlig ikke være en undskyldning for ikke generelt at rette
 igennem i alle de tilfælde, hvor der ikke er nogen tvivl.
 Der er i øvrigt kun 2 veje med Dr.
 Den ene Dronning Ingrid og den anden Doktor Lassen.

Sdr. er der nok også nogle af. Og Ø. 

Men jeg er helt enig.
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

[Talk-dk] Adresseknuder

2014-10-15 Thread Niels Elgaard Larsen

Nu har vi en masse adresseknuder som vi i 3-4 år har vidst er forkerte.

Det synes jeg er uholdbart - vi risikerer at sendte brugere på vildspor
med data som vi godt ved er forkert.

Når jeg ikke bare selv er begyndt at rette det, er det for ikke at komme
i konflikt med automatiske adresseimporteringer.

Vi har i årevis fundet fejl i adressedata, men det er en ret lille del,
der bliver rettet i OSAK. Jeg synes ikke, vi kan forsvare at vente
længere, mens vi har fejlagtige data i OSM.

Det jeg synes burde ske er:

Adresseknuder, som har forkerte koordinater, skal bare slettes. De skal
ikke igen importeres fra OSAK så længe de har samme koordinater.

Adresser der er upræcise, kan flyttes til deres rigtige placering, hvis
den kendes. Når/hvis de får nye koordinater i OSAK, kan koordinaterne i
OSM opdateres.

Men hvis vi sletter adresseknuder, sletter vi også Fixme-s, hvilket gør
det endnu mindre sandsynligt at de bliver rettet i OSAK. Og hvis de er
slettet, er det svært for en adresseimporter, at vide at den ikke skal
importere dem igen.

Så vi kunne:

1. Vedligeholde en liste over slettede adresseknuder med timestamps og
koordinater.

eller

2. undlade at slette dem og i stedet fx udskifte addr:housenumber tagget
med
do_not_use:addr:housenumberhttp://wiki.openstreetmap.org/wiki/Key:addr:housenumber



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

[Talk-dk] Adresseknuder

2014-10-15 Thread Niels Elgaard Larsen

Nu har vi en masse adresseknuder som vi i 3-4 år har vidst er forkerte.

Det synes jeg er uholdbart - vi risikerer at sendte brugere på vildspor
med data som vi godt ved er forkert.

Når jeg ikke bare selv er begyndt at rette det, er det for ikke at komme
i konflikt med automatiske adresseimporteringer.

Vi har i årevis fundet fejl i adressedata, men det er en ret lille del,
der bliver rettet i OSAK. Jeg synes ikke, vi kan forsvare at vente
længere, mens vi har fejlagtige data i OSM.

Det jeg synes burde ske er:

Adresseknuder, som har forkerte koordinater, skal bare slettes. De skal
ikke igen importeres fra OSAK så længe de har samme koordinater.

Adresser der er upræcise, kan flyttes til deres rigtige placering, hvis
den kendes. Når/hvis de får nye koordinater i OSAK, kan koordinaterne i
OSM opdateres.

Men hvis vi sletter adresseknuder, sletter vi også Fixme-s, hvilket gør
det endnu mindre sandsynligt at de bliver rettet i OSAK. Og hvis de er
slettet, er det svært for en adresseimporter, at vide at den ikke skal
importere dem igen.

Så vi kunne:

1. Vedligeholde en liste over slettede adresseknuder med timestamps og
koordinater.

eller

2. undlade at slette dem og i stedet fx udskifte addr:housenumber tagget
med do_not_use:addr:housenumber




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

Re: [Talk-es] Importación de farmacias de Madrid

2014-10-15 Thread Santi Aguirre

Hola,

Ya conseguí arreglar el problema con la cuenta. Gracias! Ahora estoy
atascado en el punto 2 (no voy demasiado rápido, jeje...). Me he descargado
el subset 01 aunque no he indicado nada en la wiki porque me siento
inseguro y de momento sólo quiero probar para no liarla. Cuando intento con
Josm bajarme los datos del área, me sale el error de que el área es
demasiado grande, y por mas que he mirado y googleado no veo la forma de
ampliar la zona. Con los gpx josm permite descargar solo el área que rodea
la traza. ¿no hay algo parecido para esto?
Y bueno, si creeis que estoy demasiado verde para este trabajo decídmelo
sin problema y dejo paso a los que sabéis.

Saludos!

El 14 de octubre de 2014, 21:56, Rafael Avila Coya ravilac...@gmail.com
escribió:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hola, Santi:

 Gracias por ofrecerte a colaborar en esta importación.

 Lo de usar una cuenta específica para importar datos de terceros a
 OpenStreetMap es un requerimiento general para cualquier importación
 de datos. Está recogido en la guía de importación [1].

 En cuanto a lo que te ha ocurrido con el bloqueo de cuenta, es la
 primera vez que tengo noticia. Si es así, tiene que ser un fallo de la
 API, está claro. ¿Has intentado en poner tu nombre de usuario, sin
 contraseña y clicando en Perdió la contraseña? para intentar que te
 envíen una nueva y así recuperar tu cuenta OSM habitual? Si lo
 resuelves así, luego crea una nueva cuenta para la importación, pero
 esta vez hazlo contra una cuenta de correo-e diferente.

 Espero que puedas resolver esto y así poder seguir con el proceso.

 Un saludo cordial,

 Rafael.

 [1]

 http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_account


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

Re: [Talk-es] Importación de farmacias de Madrid

2014-10-15 Thread Jorge Sanz Sanfructuoso

Si el area es muy grande no se puede descargar para no petar el servidor.
Puedes realizar varias descargas de trozos mas pequeños.

El miércoles, 15 de octubre de 2014, Santi Aguirre aguirrera...@gmail.com
escribió:

 Hola,

 Ya conseguí arreglar el problema con la cuenta. Gracias! Ahora estoy
 atascado en el punto 2 (no voy demasiado rápido, jeje...). Me he descargado
 el subset 01 aunque no he indicado nada en la wiki porque me siento
 inseguro y de momento sólo quiero probar para no liarla. Cuando intento con
 Josm bajarme los datos del área, me sale el error de que el área es
 demasiado grande, y por mas que he mirado y googleado no veo la forma de
 ampliar la zona. Con los gpx josm permite descargar solo el área que rodea
 la traza. ¿no hay algo parecido para esto?
 Y bueno, si creeis que estoy demasiado verde para este trabajo decídmelo
 sin problema y dejo paso a los que sabéis.

 Saludos!

 El 14 de octubre de 2014, 21:56, Rafael Avila Coya ravilac...@gmail.com
 javascript:_e(%7B%7D,'cvml','ravilac...@gmail.com'); escribió:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hola, Santi:

 Gracias por ofrecerte a colaborar en esta importación.

 Lo de usar una cuenta específica para importar datos de terceros a
 OpenStreetMap es un requerimiento general para cualquier importación
 de datos. Está recogido en la guía de importación [1].

 En cuanto a lo que te ha ocurrido con el bloqueo de cuenta, es la
 primera vez que tengo noticia. Si es así, tiene que ser un fallo de la
 API, está claro. ¿Has intentado en poner tu nombre de usuario, sin
 contraseña y clicando en Perdió la contraseña? para intentar que te
 envíen una nueva y así recuperar tu cuenta OSM habitual? Si lo
 resuelves así, luego crea una nueva cuenta para la importación, pero
 esta vez hazlo contra una cuenta de correo-e diferente.

 Espero que puedas resolver esto y así poder seguir con el proceso.

 Un saludo cordial,

 Rafael.

 [1]

 http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_account




-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://blog.jorgesanzs.com/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Importación de farmacias de Madrid

2014-10-15 Thread Rafael Avila Coya

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Puedes descargar el plugin OSM Mirror. Con él puedes descargar sin
problemas.

Rafael.

On 15/10/14 21:10, Jorge Sanz Sanfructuoso wrote:
 Si el area es muy grande no se puede descargar para no petar el 
 servidor. Puedes realizar varias descargas de trozos mas pequeños.
 
 El miércoles, 15 de octubre de 2014, Santi Aguirre 
 aguirrera...@gmail.com mailto:aguirrera...@gmail.com escribió:
 
 Hola,
 
 Ya conseguí arreglar el problema con la cuenta. Gracias! Ahora
 estoy atascado en el punto 2 (no voy demasiado rápido, jeje...). Me
 he descargado el subset 01 aunque no he indicado nada en la wiki
 porque me siento inseguro y de momento sólo quiero probar para no
 liarla. Cuando intento con Josm bajarme los datos del área, me sale
 el error de que el área es demasiado grande, y por mas que he
 mirado y googleado no veo la forma de ampliar la zona. Con los gpx
 josm permite descargar solo el área que rodea la traza. ¿no hay
 algo parecido para esto? Y bueno, si creeis que estoy demasiado
 verde para este trabajo decídmelo sin problema y dejo paso a los
 que sabéis.
 
 Saludos!
 
 El 14 de octubre de 2014, 21:56, Rafael Avila Coya 
 ravilac...@gmail.com 
 javascript:_e(%7B%7D,'cvml','ravilac...@gmail.com'); escribió:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 Hola, Santi:
 
 Gracias por ofrecerte a colaborar en esta importación.
 
 Lo de usar una cuenta específica para importar datos de terceros a 
 OpenStreetMap es un requerimiento general para cualquier
 importación de datos. Está recogido en la guía de importación [1].
 
 En cuanto a lo que te ha ocurrido con el bloqueo de cuenta, es la 
 primera vez que tengo noticia. Si es así, tiene que ser un fallo de
 la API, está claro. ¿Has intentado en poner tu nombre de usuario,
 sin contraseña y clicando en Perdió la contraseña? para intentar 
 que te envíen una nueva y así recuperar tu cuenta OSM habitual? Si
 lo resuelves así, luego crea una nueva cuenta para la importación,
 pero esta vez hazlo contra una cuenta de correo-e diferente.
 
 Espero que puedas resolver esto y así poder seguir con el proceso.
 
 Un saludo cordial,
 
 Rafael.
 
 [1] 
 http://wiki.openstreetmap.org/wiki/Import/Guidelines#Use_a_dedicated_user_account

 
 
 
 
 -- Jorge Sanz Sanfructuoso - Sanchi Blog
 http://blog.jorgesanzs.com/
 
 
 ___ Talk-es mailing
 list Talk-es@openstreetmap.org 
 https://lists.openstreetmap.org/listinfo/talk-es
 

- -- 
Twitter: http://twitter.com/ravilacoya

- 

Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.

Atendendo á lexislación vixente, empregue formatos estándares e abertos.

http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJUPvEeAAoJEB3niTly2pPQI4sP/jOPax4juKqUXx4tG+xjWadU
RcJfof8FKHYwZGpS858h/PSWgiMtUnkzYthHixzYHjqY+Q26cDqvyA4nOdkOB80h
Vo8ixSj30AbufxyBOXY55/k7+Jn3YRDzHdfp4xV9e+7YElwIbPH3Sna9rKEAwwpr
5xWmN2mAzK0zmv0B6Wmf62j7azThcYI1aFFY0OJzdxWL8zOoKduuy1rFwXCgDBiC
8TMkOhJpTarNLMVbRbHiTBoFk+RM7mtq/bx6U7eNP89GhUxsKVvKiigRVQmBFAyO
zx7nZGhAZZaWil+KJQahR7Q+JMZaK3m0am1qQx9qZWT/mmxAozyk9+P8VZx0Yo6w
JnCM1db8U2cC8PGxBFLPBQiyp0lYuvz4xmyxytrfzZlSKsE39eHbmKQB96yapckf
lcLFVQgeWFw1GI9+FK5U/xv0siY6UZkxCQX4H4/fs6IUr32Do5/2QSOsCUXaqU88
LF6QvTEewlZ4C2Q7q3c4Az9NBT5Z2Sb5pHemgpArY3DxKLZ3tS7u1Bgxr1gksSs0
XE5GhayVxN74UKM/R1zpV0cxL7cy209HYAO17QrCcw3ue+pCsEiQD5U0e/mUAaNQ
Xd5pCFyNFDTmd/guIY2ZLcrW3ksLDaGsuJuIxRH7uHfZthhNV90n29LN38VFMfye
F32x3U0a5awsSV5b4kjS
=k3q1
-END PGP SIGNATURE-

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

[Talk-at] Digitalisierung historischer Landkarten

2014-10-15 Thread Gerhard Gonter

Hallo,
  bisher habe ich mich auf dieser Liste als Lurker nicht gerade
hervorgetan, aber ich verfolge die Diskussion hier dennoch mit bisher
privat motiviertem Interesse.  Nunmehr kommt ein beruflicher
Anknuepfungspunkt hinzu, daher moechte ich ein paar Worte darueber
schreiben.

Mein derzeitiges Arbeitsgebiet ist die Entwicklung und der Betrieb
eines Langzeitarchivierungssystems an der Uni Wien, welches wesentlich
von der Uni Bibiliothek vorangetrieben wird.  Dieses Archiv dient in
der Hauptsache dazu, neu entstandene Arbeiten abzulegen sowie
Digitalisate alter Bestaende (z.B. Buecher) aufzunehmen.

Im Rahmen dieser Arbeiten kommen als besonderes Projekt derzeit
*historische Landkarten* an die Reihe, deren Verarbeitung natuerlich
besondere Fragestellungen aufwirft, die mit den bisherigen Mitteln
nicht ohne Weiteres zu behandeln sind.

Das beginnt damit, dass die Scans der Karten, verglichen mit den
bisher verarbeiteten Buechern, doch recht gross sind.  Waehrend ein
Scan von einer Buchseite auch unter hohen Aufloesungen noch relativ
passabel dargestellt werden koennen, wird das beim Kartenmaterial
schwieriger.  Zum Beispiel sei eine Karte von Asien aus 1873 [1]
erwaehnt, die aus 3 * 3 Blaettern besteht, jedes der 9 TIFF Files hat
ca. 500 MB und ca. 14400 * 11400 Pixel.

Um mit Material dieser Art etwas sinnvolles anzufangen, geht es
zunaechst um Fragen der Darstellung von einzelnen Objekten sowie in
weiterer Folge um eine Sammlungsuebersicht.  So spannt sich der Bogen
von einem Zoom and Pan Image Viewer mit dazupassender serverseitger
Komponente sowie Werkzeugen zur Annotierung, insbesondere
Geo-Referenzierung.

In diesem Zusammenhang suchen wir also eine Person, die im Rahmen
eines Werkvertrags bei der Entwicklung von Software Komponenten und
dem Aufbau der Server-Infrastruktur behilflich sein kann.  Wir sind
daran interessiert, dass moeglichst weitgehend auf vorhandene Open
Source Entwicklungen zurueckgegriffen werden kann und eigene
Entwicklungen entweder zur Verbesserung bestehender Software beitragen
oder noetigenfalls extra erstellte Software ebenfalls unter einer Open
Source Lizenz zugaenglich gemacht wird.

Unsere Archivierungsloesung laeuft derzeit unter Linux mit einem
Fedora Commons [2] Kern und darum herum eine Catalyst Anwendung sowei
eine Menge Perl.  Weiters wird derzeit viel mit AngularJS
dazuentwickelt.  Die Komponenten sollten so gut es geht eigenstaendig
sein und via APIs auf das Archiv zugreifen, sodass damit (von jemand
anderen oder uns) eine Docked Application gebaut werden kann. Der
Link eod Digitalisat bestellen auf der oben erwaehnten Aleph Seite
[1] koennte so auf eine derartige Applikations-Seite verlinkbar
werden.

Vielleicht ist jemand von dieser Liste bereit, sich mit uns
(devel.phai...@univie.ac.at) in Verbindung zu setzen um auf Basis
eines Werkvertrags an einer derartigen Entwicklung mitzuarbeiten.
Selbstverstaendlich wuerde ich mich auch ueber Hinweise auf andere
Listen, an die ich mich wenden koennte, sowie andere sachdienliche
Hinweise freuen.

References:
• [1] http://ubdata.univie.ac.at/AC04291236
• [2] https://github.com/fcrepo3

mit freundlichen Gruessen, Gerhard Gonter

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

Re: [Talk-at] Digitalisierung historischer Landkarten

2014-10-15 Thread Walter Nordmann


Hi Gerhard,

wende dich doch bitte auch an das deutsche Forum: 
http://forum.openstreetmap.org/viewtopic.php?id=19886 Dort gibt es die 
sog. Historische Objektkarte, die auch sicher was mit dem Thema zu tun 
haben kann. Zumindest sind die Kollegen da sehr heftig zugange.


Bin mir nicht sicher, ob die du nicht längst schon kennst, aber sicher 
ist sicher.


Gruss
walter

ps: im Forum kannst du dich einfach mit deiner OSM-Id und deinem 
OSM-Passwort anmelden; Registrieren ist nicht notwendig.



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

Re: [Talk-at] Digitalisierung historischer Landkarten

2014-10-15 Thread Gerhard Gonter

2014-10-15 12:18 GMT+02:00 Walter Nordmann wnordm...@gmx.de:
 Hi Gerhard,

 wende dich doch bitte auch an das deutsche Forum:
 http://forum.openstreetmap.org/viewtopic.php?id=19886 Dort gibt es die sog.
 Historische Objektkarte, die auch sicher was mit dem Thema zu tun haben
 kann. Zumindest sind die Kollegen da sehr heftig zugange.

Ah, danke fuer den Tip, das ist schon eine spannende Sache.

 Bin mir nicht sicher, ob die du nicht längst schon kennst, aber sicher ist
 sicher.

Nein, das obige Topic kannte ich bisher nicht.  Die Foren verschwinden
mir immer aus dem Gesichtsfeld.

 ps: im Forum kannst du dich einfach mit deiner OSM-Id und deinem
 OSM-Passwort anmelden; Registrieren ist nicht notwendig.

Exzellent, das habe ich gerade gerade gemacht.  Ich lass mal die Mail
kreisen, vielleicht gibt es jemand in der Naehe, der uns unterstuetzen
mag.  Den obigen Thread werde ich gleich naeher in Augenschein nehmen.

mit freundlichen Gruessen, Gerhard Gonter

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

Re: [Talk-at] Digitalisierung historischer Landkarten

2014-10-15 Thread Friedrich Volkmann

On 15.10.2014 12:18, Walter Nordmann wrote:
 wende dich doch bitte auch an das deutsche Forum:
 http://forum.openstreetmap.org/viewtopic.php?id=19886 Dort gibt es die sog.
 Historische Objektkarte, die auch sicher was mit dem Thema zu tun haben
 kann.

Das ist was ganz anderes. Das ist eine neue Karte, in der historische (d.h.
alte) Objekte eingezeichnet sind. In Gerhards Digitalisierungsprojekt sind
die Karten selber alt. Im Grunde ist es auch ganz egal, wie alt die Karten
sind. Die Aufgabe ist die Digitalisierung gedruckter Karten. Ihr Alter macht
technisch keine Unterschied (wenn man vom Erhaltungszustand absieht).

Auf Wikimedia Commons hat vor allem ein gewisser Josef Moser
(http://commons.wikimedia.org/wiki/Special:Contributions/Josef_Moser) eine
Menge Scans alter Karten (Josephinische Landesaufnahme, Franziszeische
Landesaufnahme, Franzisco-Josephinische Landesaufnahme) hochgeladen. Die
sind leider nicht vollständig, aber die Qualität ist gut und vielleicht kann
man sich, zumindest was das Einscannen betrifft, zusammenreden statt das Rad
ein zweites Mal zu erfinden.

Ein weiterer Kandidat für Erfahrungsaustausch ist die Geologische
Bundesanstalt, denn die hat etliche geologische Karten digitalisiert.

Abgesehen von deren Lösung wäre die Anzeige vielleicht mit einem Tile-Server
machbar - das ist recht performant, weil keine Bilddaten berechnet werden
müssen. Die Annotierung schreit nach Openlayers oder Leaflet.

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

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

[Talk-pt] Um exemplo onde o OSM daria jeito

2014-10-15 Thread Rui Oliveira

Embora não necessariamente relacionado com o OSM, vi esta notícia e
lembrei-me logo, aqui está um exemplo curioso e interessante de onde o OSM
daria jeito!

http://www.theverge.com/2014/10/14/6974367/private-mailmen-are-mapping-brazils-slums-by-hand
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-lv] proposed ceļi

2014-10-15 Thread Marat

Kamēr OSMā joprojām eksistē fantāziju augļu projekti, īstie nemaz
nav iezīmēti
:(

https://www.dropbox.com/s/velse4fb2jruw6d/IMG_1045.JPG?dl=0

http://www.openstreetmap.org/?mlat=57.0104mlon=24.0639#map=16/57.0104/24.0639

Internetā neko saistītu nevaru atrast.

2013-11-26 13:25 GMT+02:00 Rich ric...@nakts.net:

On 11/19/2013 04:23 PM, Raitis U. wrote:
labojam, izmantojam, utt.
+ parokoties pa arhīvu var pameklēt vēl kaut ko interesantu, bet sacerēt
prozu noteikti nav mans aicinājums.
https://lists.openstreetmap.org/pipermail/talk-lv/

ai, teemas netruukst... truukst laiks, lai par taam ko uzrakstiitu :)

2013/11/19 Rich ric...@nakts.net mailto:ric...@nakts.net

On 11/18/2013 02:14 PM, Gasha wrote:

Mazliet pielabot, un sanāktu ideāli labs raksta gabaliņš OSM.lv
blogam.

tagad tev tikai jaapierunaa raiti ;)

On 11/15/2013 11:17 PM, Raitis U. wrote:
OSM ir vienīgais avots, kur plānotā informācija ir vienkopus un
viegli
pieejama.
Vislielākā sāpe laikam ir tas, ka renderī proposed rādās pārāk
uzkrītoši - nu tad tiltus un lielākos tālākas nākotnes
megaprojektus
pārliku uz highway=concept, kas nerādīsies kartē, bet būs
atrodami
meklētājā.
http://www.openstreetmap.org/browse/way/166445286

Par Ziemeļu koridoru - man arī nepatīk kā viņš vizuāli izskatās
kartē,
bet 1.posms tomēr pamazām kustas uz priekšu.
Ja ir vēl kāds ierosinājums, lūgums konkrēti ar piemēriem.

Teorētiski ceļa life cycle ir:
1.koncepts= 2.priekšizpēte= 3.vairāki varianti (proposed?)=
4.pieņemts variants (proposed?)= 5.pieņemts tehniskais projekts
(planned)= 6.būvniecība (construction)= 7.lietošana.
Savā ziņā interesanti paskatīties arī uz konceptiem, bet laikam
jēga
no tā ir maza.

Jautājums paliek par tagu attēlošanu un vienoties, no kura posma
zīmējam. Tad arī var sakārtot oficiālo wiki lapu.

Mans personīgais skatījums:

- highway=concept (lietot tikai trunk un primary klases šosejām
bez
pievedceļiem)

- highway=proposed (tad, kad ir jau pieņemts variants, vai arī
iezīmētas sarkanās līnijas plānojumā)
-- proposed=primary/secondary...

- highway=planned
-- planned=primary/secondary...
-- construction_start_expected=-MM-DD
-- construction_end_expected=-MM-DD

- highway=construction
-- construction=primary/secondary...
-- construction_end_expected=-MM-DD

+1 par obligātu avota norādīšanu
šeit ir citi viedokļi:

http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts

http://wiki.openstreetmap.org/wiki/Talk:Comparison_of_life_cycle_concepts#But_there.27s_more.21
http://wiki.openstreetmap.org/wiki/Key:disused
http://wiki.openstreetmap.org/wiki/Key:proposed

2013/11/15 Rich ric...@nakts.net mailto:ric...@nakts.net
mailto:ric...@nakts.net mailto:ric...@nakts.net

On 11/15/2013 11:00 AM, Normunds Rustanovics wrote:
Gluži manas domas, tāda arī bija mana pamatdoma. Sliktākais
ir,
ka tiek
zīmēti ne tikai reklāmas kampaņu projekti uz 2020. gadu,
bet arī
tādi,
kuri jau ir atcelti, vai aizvietoti ar citiem plāniem.

ideja par source= taga prasiibu man patika. varbuut kaads
aktiivaaks var
izpeetiit visus proposed un tiem, kam nav source, pazinjot
autoram.

ja kaada aplikaacija raada proposed, noteikti, noteikti
zinjojam
aplikaacijas autoram.

ja zinaami konkreeti ieziimeeti, bet atcelti gadiijumi,
iemetam info
sheit. ja vien neizraadaas, ka tomeer nav atcelti, jaanes
nost.
...
--
Rich
--
Rich
--
Rich

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

Re: [Talk-lv] proposed ceļi

2014-10-15 Thread Rich

On 15/10/14 21:21, Marat wrote:
 Kamēr OSMā joprojām eksistē fantāziju augļu projekti, īstie
 nemaz nav iezīmēti :(
 
 https://www.dropbox.com/s/velse4fb2jruw6d/IMG_1045.JPG?dl=0
 
 http://www.openstreetmap.org/?mlat=57.0104mlon=24.0639#map=16/57.0104/24.0639
 
 Internetā neko saistītu nevaru atrast.

tas nav dzelzcelja atzars ?
http://nra.lv/latvija/riga/115381-krievu-sala-kugi-bus.htm
...dzelzceļa atzara būve no stacijas Bolderāja–2 uz Krievu salu pāri
Daugavgrīvas ielai.

http://www.rop.lv/lv/multimedia/downloads/doc_download/60-rigas-brivostas-attistibas-programma-2009-g-2018-g.html
, 87. lpp. ir kaut kas liidziigs, lai gan meerogs tur taads nekaads.

laikam
http://www.ldz.lv/lv/content/stacijas-bolderāja-2-ar-savienojošo-ceļu-uz-krievu-salas-termināliem-būvniecība-0
- bet pasha projekta nav.
...
-- 
 Rich

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

[Talk-ca] Fwd: [OSM-talk] Your chance to host State of the Map 2015

2014-10-15 Thread Richard Weait

-- Forwarded message --
From: Rob Nickerson rob.j.nicker...@gmail.com
Date: Wed, Oct 15, 2014 at 1:46 PM
Subject: [OSM-talk] Your chance to host State of the Map 2015
To: OpenStreetMap t...@openstreetmap.org

Hi list members,

State of the Map conferences are a great way to bring the community
together, reach out to new members and promote innovation. I am
delighted to see that the OpenStreetMap Foundation have committed to
continuing State of the Map in 2015.

The OSMF annual SOTM complements local SOTMs {EU, US, Scotland, etc}
and to me one of the big benefits is that the Foundation remains
committed to taking SOTM to new places. Now it's your chance to host
:-)

The call for locations for SOTM 2015 is now open:

http://wiki.openstreetmap.org/wiki/State_Of_The_Map_2015/Call_for_venues

So why are you still reading this, get bidding :-)

Regards,
Rob
SotM 2013 (Birmingham) local team

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

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

Re: [Talk-cz] Smazání duplicitních budov

2014-10-15 Thread jzvc


Dne 13.10.2014 v 16:18 Petr Vejsada napsal(a):

Ahoj,

On Mon, Oct 13, 2014 at 03:33:24PM +0200, Vladimír Slávik wrote:


Co znamenají záporné id? Mám tam jednu položku a nevím...
V


záporná ID jsou čísla relací, kladná jsou čísla cest.

Samozřejmě je možno budovy opravovat ručně, ale toto jsem myslel spíš na
automatické zpracování, aby toho na to ruční zbylo co nejméně. Na ruční zbyde
7000 budov.

Šlo mi spíš o to, aby se každý, kdo chce, na to mohl podívat a zamyslel se,
co se stane, když smažu tu starší budovu z dvojice, zda je to OK a pokud ne,
tak proč.


OK, tak sem si vytah sam sebe, a muzu prihodit dalsi namitku:

http://www.openstreetmap.org/way/22663092
vs
http://www.openstreetmap.org/way/122128662

Tohle je naprosto typickej problem panelaku, ze nekdy, jsou evidovany 
jednotlivy vchody jako samostatny budovy a nekdy je to vice (nikoli 
nutne vsechny) vchodu. Pricemz z hlediska mapovani v OSM je IMO 
spravnejsi varianta rozdeleni na vchody. Uz proto, ze budova v 90% 
pripadu nebyva volne pruchozi, takze se rozhodne neda rict, ze je jedno, 
jakym vchodem dovnitr vlezes.


Podotykam, ze to nema zadnou souvislost s tim, jak budova vypada 
konstrukcne.


Co s tim? Napada me jedine to, ze bys musel jeste zjistovat, zda budova 
neprekryva vice budov. Muze to byt prakticky oboustrane - jak tak, ze 
starsi budova = jedna way a novejsi = nekolik, tak opacne.




--
Petr



On 12.10.2014 22:41, Petr Vejsada wrote:

Ahoj,

tak nějaký pokrok - na http://pedro.poloha.net/osm/naplacane_budovy.csv je
nová verze tabulky.





___
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-cz] Smazání duplicitních budov

2014-10-15 Thread Petr Vejsada

Ahoj,

na uvedeném místě dříve byly v OSM 3 budovy. V RUIAN je místo dvou jedna
velká. Při rychlém trasování někdo rychle klikal a zbytek ho nezajímal -
prostě zvětšil jednu z těch dvou budov a už nesmazal tu, kterou přeplácl.

Co s tím v rámci automatických oprav - správně stanovit cut-off. Na
http://pedro.poloha.net/osm/rgraph.jpg je rychlý histogram z R-ka. Když to
střihneme na těch 80% (jak je to teď), zmiňovaná budova se do zpracování
nedostane - má překryv asi 52%. Přitom pokryjeme většinu případů. Zachybovat
by to mohlo snad jen v případě, že bude barák s malou garáží přeplácnutý
útvarem, zahrnujícím jak barák tak garáž a ještě k tomu ten útvar bude
nejmladší. U domu s garáží by překryv mohl být přes 80%. Panelák s více než
pěti vchody by také mohl podlehnout.

Přidat počet jiných budov, které daná budova překrývá, by šlo udělat. Pak by
šlo odstraňovat tu budovu z dvojice, která se překrývá s více jinými budovami.
Udělám to, počítá se, není všespasitelné. Jedna mrňavá budova může překrývat 2
větší tak, že bude ležet uprostřed těch velkých a nebo třeba takovýto masajr -
budova 257008529 překrývá 3 jiné, ale je potřeba si to natáhnout do JOSM, aby
bylo alespoň znázornitelné, jak velký bordel to je.

Až se to dopočítá, dám aktuální tabulku na web.

--
Petr

Dne St 15. října 2014 15:33:12, jzvc napsal(a):

Dne 13.10.2014 v 16:18 Petr Vejsada napsal(a):
Ahoj,

On Mon, Oct 13, 2014 at 03:33:24PM +0200, Vladimír Slávik wrote:
Co znamenají záporné id? Mám tam jednu položku a nevím...
V

záporná ID jsou čísla relací, kladná jsou čísla cest.

Samozřejmě je možno budovy opravovat ručně, ale toto jsem myslel spíš na
automatické zpracování, aby toho na to ruční zbylo co nejméně. Na ruční
zbyde 7000 budov.

Šlo mi spíš o to, aby se každý, kdo chce, na to mohl podívat a zamyslel
se,
co se stane, když smažu tu starší budovu z dvojice, zda je to OK a pokud
ne, tak proč.

OK, tak sem si vytah sam sebe, a muzu prihodit dalsi namitku:

http://www.openstreetmap.org/way/22663092
vs
http://www.openstreetmap.org/way/122128662

Tohle je naprosto typickej problem panelaku, ze nekdy, jsou evidovany
jednotlivy vchody jako samostatny budovy a nekdy je to vice (nikoli
nutne vsechny) vchodu. Pricemz z hlediska mapovani v OSM je IMO
spravnejsi varianta rozdeleni na vchody. Uz proto, ze budova v 90%
pripadu nebyva volne pruchozi, takze se rozhodne neda rict, ze je jedno,
jakym vchodem dovnitr vlezes.

Podotykam, ze to nema zadnou souvislost s tim, jak budova vypada
konstrukcne.

Co s tim? Napada me jedine to, ze bys musel jeste zjistovat, zda budova
neprekryva vice budov. Muze to byt prakticky oboustrane - jak tak, ze
starsi budova = jedna way a novejsi = nekolik, tak opacne.

--
Petr

On 12.10.2014 22:41, Petr Vejsada wrote:
Ahoj,

tak nějaký pokrok - na http://pedro.poloha.net/osm/naplacane_budovy.csv
je
nová verze tabulky.

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

Re: [Talk-cz] dotaz na MTBmap

2014-10-15 Thread Petr Holub

 chtěl jsem se zeptat co se děje s MTBmap - již týden se k ní nemohu připojit

Aspon zakladni dlazdice uz jedou od pondelka:
http://raw.mtbmap.cz/

Petr


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

Re: [Talk-cz] Smazání duplicitních budov

2014-10-15 Thread Petr Vejsada

Tak, je tam aktuální i s počtem jiných budov, které daná budova překrývá. 
max=5.

--
Petr

Dne St 15. října 2014 19:55:51, Petr Vejsada napsal(a):

 http://pedro.poloha.net/osm/naplacane_budovy.csv


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

[OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

En tentant de corriger des erreurs de frontières incomplètes dans Osmose,
je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans ce qui ne
,e semble pas être des quartiers mais des noms de parcelles (ou groupes de
parcelles). Y compris des parcelles homonymes et limitrophes l'une de
l'autre.
Les noms sont parfois des lieux-dits, ou des noms de rues.

Exemple autour de ceci:

http://www.openstreetmap.org/way/306246629

Le chemin est isolé mais la frontière n'est pas fermée (il n'est encore
dans aucune relation mais a déjà un tag admin_level 10), et la commune
n'est visiblement pas entièrement découpée, je ne vois pas comment corriger
ces relations administrative pour les fermer correctement, et comment les
retaguer correctement si ce n'est pas administratif.

Pour l'instant je n'ai rien supprimé (ce tracé est tout demême complexe
pour une seule commune), juste levé quelques anomalies géométriques pour
vérifier la cohérence de ce découpage dont la classification reste tout de
même à revoir si on doit garder ce découpage pour une certaine utilité (il
ne me semble pas qu'il soi approprié pour les lieux-dits). Je me demande
d'où ce découpage est issu : est-ce que c'est le découpage des zones
cadastrales ? L'auteur comptait-il poursuivre ensuite avec les parcelles
individuelles ?

Jusqu'à présent on utilisait le niveau 9 pour les arrondissements de Paris
Lyon Marseille o pour les communes associées au sein d'une même commune; le
niveau 10 pour des quartiers réels, mais pas pour un découpage quasi
parcellaire comme ici.

Note: je ne m'adresse pas spécifiquement à cet auteur (il peut s'exprimer;
je ne lui tape pas dessus et il peut avoir des intentions louables), si sur
le fait que ce découpage soit incomplet, mais juste sur la question de la
pertinence de ces données (pérennité, adéquation à une utilisation par
exemple pour des plans immobiliers) et surtout de leur classification, pour
que cela ne nuise pas aux autres utilisations des données (j'ai peur que ça
pollue les recherches de Nominatim par exemple, ou que cela nuise à la
recherche d'adresses et lieux-dits, liée au projet BANO).

Le risque de conserver ce découpage au niveau admin 10 c'est la confusion
qui pourrait naitre du fait de l'association de communes voisines, ou d'une
réelle division administrative pour les services intercommunaux (comme à
Nantes avec ses pôles de proximité au sein de la métropole) qui sera
nettement plus utile à mon avis.

Si cela représente des zones cadastrales, cela pourrait être utile à plus
grande échelle mais je pense qu'avant ça on aimerait plutôt avoir d'abord
le découpage INSEE des IRIS (les deux projets ne sont pas incompatibles et
peuvent coexister), à condition de décider des bons tags à utiliser:

En Espagne ils ont des découpages sous-communaux très détaillés pour les
unités de population (traduction approchante, le terme exact varie selon
les communautés autonomes ou villes), et ça sert de brique de base pour les
statistiques économiques, les découpages électoraux (par exemple bureaux de
vote) ou la fiscalité locale (taux d'imposition foncière ou locative), les
plans et règlements d'urbanisme, la gestion des réseaux publics et des
ressources...

En France on a encore du mal avec
- les IRIS dont l'usage est encore mal maitrisé (boundary=statistical)- On
aimerait avoir des données exploitables dessus.
- le découpage pour les opérations électorales des bureaux de vote
(boundary=electoral)
- le zonage urbain légal (celui qui définit les limites d'agglomérations
selon les distances maximales entre bâtiments et au delà les poles urbains;
boundary=urban?),
- les bassins d'emploi (pas nécessairement les mêmes découpages que les
intercommunalités et syndicats mixtes)
la carte scolaire publique, le zonage des services sociaux et
médico-hospitalier, le
- le découpage judiciaire des tribunaux (boundary=judiciary, comme en
Belgique),
- le découpage des secteurs de police (révisé avec police et gendarmerie,
plus fin que le découpage judiciaire avec des secteurs sur plusieurs
secteurs judiciaires)
- les régions de défense nationale (boundary=military),
- le découpage civil des régions aériennes autour des centres de contrôle
aérien (boundary=aerial?),
- les limites de compétence des ports autonomes (définis par décret depuis
1961, étendus vers 2003, et indépendant des intercommunalités),
- les zones franches (quel tags?)
- etc.

Et tout ça bien avant le découpage historique des anciennes planches
cadastrales (pour ensuite y numéroter les parcelles et le calcul des taxes
foncières ou la gestion des domaines publics locaux ou nationaux, ou la
gestion des concessions publiques au privé; y compris les mines, forages et
conduites de transport d'eau et d'énergie) d'avant leur numérisation (OSM
n'ayant pas vocation non plus à remplacer le cadastre pour ses aspects
légaux et réglementaires dans des opérations de cession immobilière, les
successions, la fiscalité, les plans d'urbanisme légaux et les permis de
construire, la

[OSM-talk-fr] Transformation node en way sur Josm

Bonjour,

existe t-il une possibilité de transformer un node en way (polygone) le but
de l'opération étant de ne pas perdre l'historique des tags présents sur
l'objet d'origine.

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

Re: [OSM-talk-fr] relations person dans OSM ?? Mauvaise interprétation par P. V.

2014-10-15 Thread Pieren

2014-10-14 22:07 GMT+02:00 sylvain letuffe lis...@letuffe.org:

 Mais contient aussi une partie géographique (naissance, commémoration,
 plaques, tombe, etc.). Plutôt que de tout rejeter en bloc, je m'interroge sur
 l'intérêt de cette partie, savoir si une autre manière de stocker cette
 information existe dans osm, ou s'il est préférable de recommander à ceux qui
 ont lancé cette proposition d'aller faire ça ailleurs.

Cette relation vise à modéliser une personne sans restrictions, pas
seulement à résoudre un problème de plusieurs noms sur une tombe.
Elle suggère même de pouvoir l'utiliser pour les vivants. Il y a donc
bien une intention, celle de représenter les personnes dans OSM, avec
une porte ouverte à toutes les extensions possibles et imaginables
comme on en voit déjà.
Cette proposition aurait été mieux acceptée avec un autre nom (par ex.
deceased_person) et une autre intention avec des limitations claires
dans le libellé pour éviter toute forme d'abus (limité aux tombes et
monuments, limité aux morts, limité aux personnages connus et sinon,
conditionné aux législations locales sur la constitution de bases de
données nominatives), ne pas mettre d'autres infos comme les lieux de
naissance ou liens familiaux pour éviter une exploitation
généalogiste, etc. Et malgré tout, il reste d'autres solutions pour
résoudre le cas des tombes avec plusieurs noms.

Dans le même esprit, on pourrait imaginer des relations qui modélisent
les véhicules. Certains pourraient aussi y trouver un intérêt
(anciennes loco, entretien réseau de bus, etc). Ca n'est pas pour
autant une bonne idée pour OSM.

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

Re: [OSM-talk-fr] Transformation node en way sur Josm

2014-10-15 Thread Jo

A mon avis il n'y a rien d'automatique qui le fait.

Ce que tu peux faire (en JOSM) c'est sélectionner le node, Ctrl-c

Dessiner le way, puis Ctrl-Shift-V pour coller les tags.

Sélectionner à nouveau le node, enlever tous les tags, puis
Shift-sélectionner un des nodes du nouveau way, puis m (merge).

L'historique du node est maintenant préservé, mais il n'y aura personne qui
s'en rendra compte...

Polyglot

2014-10-15 10:36 GMT+02:00 Mides mides@gmail.com:

 Bonjour,

 existe t-il une possibilité de transformer un node en way (polygone) le
 but de l'opération étant de ne pas perdre l'historique des tags présents
 sur l'objet d'origine.

 Michel

 ___
 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] Transformation node en way sur Josm

2014-10-15 Thread Frédéric Rodrigo

Non, tu ne peux pas faire ça sans perdre l'historique. Plus le même 
identifiant, plus le même type d'objet.


Tu peux juste copier le tags sur le nouvel objet.

Le 15/10/2014 10:36, Mides a écrit :

Bonjour,

existe t-il une possibilité de transformer un node en way (polygone) le
but de l'opération étant de ne pas perdre l'historique des tags présents
sur l'objet d'origine.

Michel


___
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] QuickOSM : plugin QGIS pour interroger l'overpass

Bonjour,

Il existe depuis peu un plugin QGIS permettant d'interroger l'OverpassAPI.
Il s'agit du plugin QuickOSM :
- utilisation des clés / valeurs via autocompletion
- chargement à partir d'une emprise géographique ou d'une localité grâce à
Nominatim
- utilisations des actions pour une édition dans JOSM ou un accès à des
pages Web tel que la page Wikipedia
- enregistrement de ses requêtes
- modification de la valeur par défaut pour l'emprise géographique ou la
localité Nominatim
- application automatique de symbologies si possible
- utilisation de QuickOSM au sein du module de traitements de QGIS :
téléchargement de la voirie d'une commune en indiquant le code INSEE,
reprojection en 2154 puis découpage selon une zone tampon
- ouverture d'un fichier OSM local en spécifiant le fichier de
configuration d'OGR

Une petite vidéo de présentation :
https://vimeo.com/108737868

J'ai développé ce projet dans le cadre d'un stage chez 3Liz :
http://www.3liz.com/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Transformation node en way sur Josm

2014-10-15 Thread JB

Encore plus rapide, tu sélectionnes le nœud et le way, puis Ctrl+Maj+G, 
le nœud disparait et le way récupère ses tags… Bon, pas son historique, 
par contre.

JB.

Le 15/10/2014 10:44, Jo a écrit :

A mon avis il n'y a rien d'automatique qui le fait.

Ce que tu peux faire (en JOSM) c'est sélectionner le node, Ctrl-c

Dessiner le way, puis Ctrl-Shift-V pour coller les tags.

Sélectionner à nouveau le node, enlever tous les tags, puis 
Shift-sélectionner un des nodes du nouveau way, puis m (merge).


L'historique du node est maintenant préservé, mais il n'y aura 
personne qui s'en rendra compte...


Polyglot

2014-10-15 10:36 GMT+02:00 Mides mides@gmail.com 
mailto:mides@gmail.com:


Bonjour,

existe t-il une possibilité de transformer un node en way
(polygone) le but de l'opération étant de ne pas perdre
l'historique des tags présents sur l'objet d'origine.

Michel

___
Talk-fr mailing list
Talk-fr@openstreetmap.org mailto: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] Transformation node en way sur Josm

Je viens d'effectuer cette manip (merge du node) et effectivement on arrive
par cet artifice à faire suivre l'historique du node sur le nouveau
way(polygone), du moins sur un node du way.

C'est bon à savoir, mais je ne vais peut être pas l'utiliser dans mon cas,
 je trouve que cela pollue un peu l'objet final.

Merci pour ces réponses.

Michel



Le 15 octobre 2014 10:44, Jo winfi...@gmail.com a écrit :

 A mon avis il n'y a rien d'automatique qui le fait.

 Ce que tu peux faire (en JOSM) c'est sélectionner le node, Ctrl-c

 Dessiner le way, puis Ctrl-Shift-V pour coller les tags.

 Sélectionner à nouveau le node, enlever tous les tags, puis
 Shift-sélectionner un des nodes du nouveau way, puis m (merge).

 L'historique du node est maintenant préservé, mais il n'y aura personne
 qui s'en rendra compte...

 Polyglot

 2014-10-15 10:36 GMT+02:00 Mides mides@gmail.com:

 Bonjour,

 existe t-il une possibilité de transformer un node en way (polygone) le
 but de l'opération étant de ne pas perdre l'historique des tags présents
 sur l'objet d'origine.

 Michel

 ___
 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] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

Les zones dont tu parles pour moi c'est pas du boundary, c'est du découpage
cadastre des lieu-dits (voisinage dans un village ou quartier en ville ou
hameau) En principe moi je fais juste un noeud toponyme mais on peu faire
des zones toponymes et faire le lien vers le nom du contour administratif
en question. d'ailleurs c'est bizarre car aucun tracé n'est fermé vu que le
nom est sur le tracé

on peut mettre un is_in=* pour lier avec le boundary de la commune
certains font des landuse= residential mais je trouve ça pourri pour  faire
des toponymes. Moi je préfère juste faire comme ici :
http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
dans le polygone mais sur un noeud et les lier si besoin...(il y a
peut-être mieux)

Le landuse est un autre objet pour moi. Mais je vais pas revenir sur ça
c'est pas le sujet.

Pour réparer moi je fais ça dans JOSM en important que le tronçon boundary
en question par son id et en important uniquement les relations. Après en
cas de problèmes JOSM demande de corriger les incohérence avant de faire la
sauvegarde. J'avais fait une connerie de ce type sur Montpellier. J'ai
juste refermé le way et fini.

En même temps iD fou un peu la merde:
 Si tu coupes un polygon pour en faire deux il coupe toute les relations et
ça ressemble un peu à ce que tu présentes.




Le 15 octobre 2014 10:14, Philippe Verdy verd...@wanadoo.fr a écrit :

 En tentant de corriger des erreurs de frontières incomplètes dans Osmose,
 je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans ce qui ne
 ,e semble pas être des quartiers mais des noms de parcelles (ou groupes de
 parcelles). Y compris des parcelles homonymes et limitrophes l'une de
 l'autre.
 Les noms sont parfois des lieux-dits, ou des noms de rues.

 Exemple autour de ceci:

 http://www.openstreetmap.org/way/306246629

 Le chemin est isolé mais la frontière n'est pas fermée (il n'est encore
 dans aucune relation mais a déjà un tag admin_level 10), et la commune
 n'est visiblement pas entièrement découpée, je ne vois pas comment corriger
 ces relations administrative pour les fermer correctement, et comment les
 retaguer correctement si ce n'est pas administratif.

 Pour l'instant je n'ai rien supprimé (ce tracé est tout demême complexe
 pour une seule commune), juste levé quelques anomalies géométriques pour
 vérifier la cohérence de ce découpage dont la classification reste tout de
 même à revoir si on doit garder ce découpage pour une certaine utilité (il
 ne me semble pas qu'il soi approprié pour les lieux-dits). Je me demande
 d'où ce découpage est issu : est-ce que c'est le découpage des zones
 cadastrales ? L'auteur comptait-il poursuivre ensuite avec les parcelles
 individuelles ?

 Jusqu'à présent on utilisait le niveau 9 pour les arrondissements de Paris
 Lyon Marseille o pour les communes associées au sein d'une même commune; le
 niveau 10 pour des quartiers réels, mais pas pour un découpage quasi
 parcellaire comme ici.

 Note: je ne m'adresse pas spécifiquement à cet auteur (il peut s'exprimer;
 je ne lui tape pas dessus et il peut avoir des intentions louables), si sur
 le fait que ce découpage soit incomplet, mais juste sur la question de la
 pertinence de ces données (pérennité, adéquation à une utilisation par
 exemple pour des plans immobiliers) et surtout de leur classification, pour
 que cela ne nuise pas aux autres utilisations des données (j'ai peur que ça
 pollue les recherches de Nominatim par exemple, ou que cela nuise à la
 recherche d'adresses et lieux-dits, liée au projet BANO).

 Le risque de conserver ce découpage au niveau admin 10 c'est la confusion
 qui pourrait naitre du fait de l'association de communes voisines, ou d'une
 réelle division administrative pour les services intercommunaux (comme à
 Nantes avec ses pôles de proximité au sein de la métropole) qui sera
 nettement plus utile à mon avis.

 Si cela représente des zones cadastrales, cela pourrait être utile à plus
 grande échelle mais je pense qu'avant ça on aimerait plutôt avoir d'abord
 le découpage INSEE des IRIS (les deux projets ne sont pas incompatibles et
 peuvent coexister), à condition de décider des bons tags à utiliser:

 En Espagne ils ont des découpages sous-communaux très détaillés pour les
 unités de population (traduction approchante, le terme exact varie selon
 les communautés autonomes ou villes), et ça sert de brique de base pour les
 statistiques économiques, les découpages électoraux (par exemple bureaux de
 vote) ou la fiscalité locale (taux d'imposition foncière ou locative), les
 plans et règlements d'urbanisme, la gestion des réseaux publics et des
 ressources...

 En France on a encore du mal avec
 - les IRIS dont l'usage est encore mal maitrisé (boundary=statistical)- On
 aimerait avoir des données exploitables dessus.
 - le découpage pour les opérations électorales des bureaux de vote
 (boundary=electoral)
 - le zonage urbain légal (celui qui définit les limites d'agglomérations
 selon les

Re: [OSM-talk-fr] Transformation node en way sur Josm

2014-10-15 Thread Vincent de Château-Thierry

Selon JB jb...@mailoo.org:

 Encore plus rapide, tu sélectionnes le noeud et le way, puis Ctrl+Maj+G,
 le noeud disparait et le way récupère ses tags. Bon, pas son historique,
 par contre.

Raccourci actif via ce pratique plugin :
http://josm.openstreetmap.de/wiki/Help/Plugin/UtilsPlugin2

vincent

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

Re: [OSM-talk-fr] Transformation node en way sur Josm

2014-10-15 Thread Jo

Dans l'extension building tools il y a également la possibilité de dessiner
un bâtiment au dessus d'un noeud ayant une adresse. Le noeud disparaît et
les tags sont transféré automatiquement sur un closed way avec des angles
de 90 degrées.

Il me semble que c'est la façon la plus vite qu'il ya.

Après cela tu peux adapter le bâtiment avec x. Très pratique.

L'historique n'est pas préservé, bien sûr.

Jo


2014-10-15 11:03 GMT+02:00 Mides mides@gmail.com:

 Je viens d'effectuer cette manip (merge du node) et effectivement on
 arrive par cet artifice à faire suivre l'historique du node sur le nouveau
 way(polygone), du moins sur un node du way.

 C'est bon à savoir, mais je ne vais peut être pas l'utiliser dans mon cas,
  je trouve que cela pollue un peu l'objet final.

 Merci pour ces réponses.

 Michel



 Le 15 octobre 2014 10:44, Jo winfi...@gmail.com a écrit :

 A mon avis il n'y a rien d'automatique qui le fait.

 Ce que tu peux faire (en JOSM) c'est sélectionner le node, Ctrl-c

 Dessiner le way, puis Ctrl-Shift-V pour coller les tags.

 Sélectionner à nouveau le node, enlever tous les tags, puis
 Shift-sélectionner un des nodes du nouveau way, puis m (merge).

 L'historique du node est maintenant préservé, mais il n'y aura personne
 qui s'en rendra compte...

 Polyglot

 2014-10-15 10:36 GMT+02:00 Mides mides@gmail.com:

 Bonjour,

 existe t-il une possibilité de transformer un node en way (polygone) le
 but de l'opération étant de ne pas perdre l'historique des tags présents
 sur l'objet d'origine.

 Michel

 ___
 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] Transformation node en way sur Josm

A ce propos, existe t-il d'autres pas d'aide sur les shorcuts Josm, hormis
celle-ci https://josm.openstreetmap.de/wiki/Shortcuts . *(où il ne figure
pas cette combinaison : Ctrl+Maj+G )*

Michel

Le 15 octobre 2014 10:59, JB jb...@mailoo.org a écrit :

  Encore plus rapide, tu sélectionnes le nœud et le way, puis Ctrl+Maj+G,
 le nœud disparait et le way récupère ses tags… Bon, pas son historique, par
 contre.
 JB.

 Le 15/10/2014 10:44, Jo a écrit :

A mon avis il n'y a rien d'automatique qui le fait.

  Ce que tu peux faire (en JOSM) c'est sélectionner le node, Ctrl-c

  Dessiner le way, puis Ctrl-Shift-V pour coller les tags.

  Sélectionner à nouveau le node, enlever tous les tags, puis
 Shift-sélectionner un des nodes du nouveau way, puis m (merge).

  L'historique du node est maintenant préservé, mais il n'y aura personne
 qui s'en rendra compte...

  Polyglot

 2014-10-15 10:36 GMT+02:00 Mides mides@gmail.com:

 Bonjour,

  existe t-il une possibilité de transformer un node en way (polygone) le
 but de l'opération étant de ne pas perdre l'historique des tags présents
 sur l'objet d'origine.

  Michel

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




 ___
 Talk-fr mailing 
 listTalk-fr@openstreetmap.orghttps://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] Transformation node en way sur Josm

2014-10-15 Thread Christian Quest

Tu as cette aide dans JOSM lui même... dans les préférences, chez moi c'est
la 7ème icone sur la gauche, celle qui représente un clavier.

Ca permet de modifier les raccourcis, mais la liste est bien utile et
surtout elle est dynamique et correspond aux plugins installés et ce
ctrl-maj-G provient d'un plugin et n'est donc pas listé dans les raccourcis
par défaut.

Le 15 octobre 2014 11:11, Mides mides@gmail.com a écrit :

 A ce propos, existe t-il d'autres pas d'aide sur les shorcuts Josm, hormis
 celle-ci https://josm.openstreetmap.de/wiki/Shortcuts . *(où il ne figure
 pas cette combinaison : Ctrl+Maj+G )*

 Michel

 Le 15 octobre 2014 10:59, JB jb...@mailoo.org a écrit :

  Encore plus rapide, tu sélectionnes le noeud et le way, puis Ctrl+Maj+G,
 le noeud disparait et le way récupère ses tags... Bon, pas son historique, 
 par
 contre.
 JB.

 Le 15/10/2014 10:44, Jo a écrit :

A mon avis il n'y a rien d'automatique qui le fait.

  Ce que tu peux faire (en JOSM) c'est sélectionner le node, Ctrl-c

  Dessiner le way, puis Ctrl-Shift-V pour coller les tags.

  Sélectionner à nouveau le node, enlever tous les tags, puis
 Shift-sélectionner un des nodes du nouveau way, puis m (merge).

  L'historique du node est maintenant préservé, mais il n'y aura personne
 qui s'en rendra compte...

  Polyglot

 2014-10-15 10:36 GMT+02:00 Mides mides@gmail.com:

 Bonjour,

  existe t-il une possibilité de transformer un node en way (polygone)
 le but de l'opération étant de ne pas perdre l'historique des tags présents
 sur l'objet d'origine.

  Michel

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




 ___
 Talk-fr mailing 
 listTalk-fr@openstreetmap.orghttps://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




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

Re: [OSM-talk-fr] Transformation node en way sur Josm

Ok, vu  Je viens d'installer ce plugin, bien pratique d'ailleurs, et le
raccourci apparaît effectivement dans la liste ( préf/ 7 ème bouton aussi
de mon coté :-) )

Michel

Le 15 octobre 2014 11:27, Christian Quest cqu...@openstreetmap.fr a écrit
:

 Tu as cette aide dans JOSM lui même... dans les préférences, chez moi
 c'est la 7ème icone sur la gauche, celle qui représente un clavier.

 Ca permet de modifier les raccourcis, mais la liste est bien utile et
 surtout elle est dynamique et correspond aux plugins installés et ce
 ctrl-maj-G provient d'un plugin et n'est donc pas listé dans les raccourcis
 par défaut.

 Le 15 octobre 2014 11:11, Mides mides@gmail.com a écrit :

 A ce propos, existe t-il d'autres pas d'aide sur les shorcuts Josm,
 hormis celle-ci https://josm.openstreetmap.de/wiki/Shortcuts . *(où il
 ne figure pas cette combinaison : Ctrl+Maj+G )*

 Michel

 Le 15 octobre 2014 10:59, JB jb...@mailoo.org a écrit :

  Encore plus rapide, tu sélectionnes le nœud et le way, puis Ctrl+Maj+G,
 le nœud disparait et le way récupère ses tags… Bon, pas son historique, par
 contre.
 JB.

 Le 15/10/2014 10:44, Jo a écrit :

A mon avis il n'y a rien d'automatique qui le fait.

  Ce que tu peux faire (en JOSM) c'est sélectionner le node, Ctrl-c

  Dessiner le way, puis Ctrl-Shift-V pour coller les tags.

  Sélectionner à nouveau le node, enlever tous les tags, puis
 Shift-sélectionner un des nodes du nouveau way, puis m (merge).

  L'historique du node est maintenant préservé, mais il n'y aura personne
 qui s'en rendra compte...

  Polyglot

 2014-10-15 10:36 GMT+02:00 Mides mides@gmail.com:

 Bonjour,

  existe t-il une possibilité de transformer un node en way (polygone)
 le but de l'opération étant de ne pas perdre l'historique des tags présents
 sur l'objet d'origine.

  Michel

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




 ___
 Talk-fr mailing 
 listTalk-fr@openstreetmap.orghttps://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




 --
 Christian Quest - OpenStreetMap France

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


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

Re: [OSM-talk-fr] QuickOSM : plugin QGIS pour interroger l'overpass

2014-10-15 Thread Maxime Résibois

Bonjour,

Justement hier j'ai testé ton plugin pour la première fois : je le trouve
tout simplement génial et hyper complet! Merci beaucoup pour ce travail qui
va rendre les données OSM encore plus simplement accessibles aux
géomaticiens.

Maxime

Le 15 octobre 2014 10:52, Etienne Trimaille etienne.trimai...@gmail.com a
écrit :

 Bonjour,

 Il existe depuis peu un plugin QGIS permettant d'interroger l'OverpassAPI.
 Il s'agit du plugin QuickOSM :
 - utilisation des clés / valeurs via autocompletion
 - chargement à partir d'une emprise géographique ou d'une localité grâce à
 Nominatim
 - utilisations des actions pour une édition dans JOSM ou un accès à des
 pages Web tel que la page Wikipedia
 - enregistrement de ses requêtes
 - modification de la valeur par défaut pour l'emprise géographique ou la
 localité Nominatim
 - application automatique de symbologies si possible
 - utilisation de QuickOSM au sein du module de traitements de QGIS :
 téléchargement de la voirie d'une commune en indiquant le code INSEE,
 reprojection en 2154 puis découpage selon une zone tampon
 - ouverture d'un fichier OSM local en spécifiant le fichier de
 configuration d'OGR

 Une petite vidéo de présentation :
 https://vimeo.com/108737868

 J'ai développé ce projet dans le cadre d'un stage chez 3Liz :
 http://www.3liz.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] QuickOSM : plugin QGIS pour interroger l'overpass

Je viens de tester, super plugin, très souple, puissant, convivial et qui
va certainement rendre pas mal de services dans l’automatisation des
requêtes.

Michel

Le 15 octobre 2014 10:52, Etienne Trimaille etienne.trimai...@gmail.com a
écrit :

 Bonjour,

 Il existe depuis peu un plugin QGIS permettant d'interroger l'OverpassAPI.
 Il s'agit du plugin QuickOSM :
 - utilisation des clés / valeurs via autocompletion
 - chargement à partir d'une emprise géographique ou d'une localité grâce à
 Nominatim
 - utilisations des actions pour une édition dans JOSM ou un accès à des
 pages Web tel que la page Wikipedia
 - enregistrement de ses requêtes
 - modification de la valeur par défaut pour l'emprise géographique ou la
 localité Nominatim
 - application automatique de symbologies si possible
 - utilisation de QuickOSM au sein du module de traitements de QGIS :
 téléchargement de la voirie d'une commune en indiquant le code INSEE,
 reprojection en 2154 puis découpage selon une zone tampon
 - ouverture d'un fichier OSM local en spécifiant le fichier de
 configuration d'OGR

 Une petite vidéo de présentation :
 https://vimeo.com/108737868

 J'ai développé ce projet dans le cadre d'un stage chez 3Liz :
 http://www.3liz.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] Pour les amateurs de beaux rendus, même pour les cyclistes

2014-10-15 Thread JB

Vu passer sur les propositions d'Image de la semaine 
(http://wiki.osm.org/wiki/Featured_image_proposals).
Tellement bluffant que je ne résiste pas à l'envie de le partager : la 
carte cyclable de la ville de Cincinnati imprimée à 9000 exemplaires, 
pure donnée OSM (+ relief). Le fichier fait 19Mo, mais ça vaut le coup !

http://www.cincymap.org/files/Cincinnati_Bike_Map.png
JB.


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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)


Bonjour

Le 15/10/2014 11:05, Jérôme Seigneuret a écrit :

d'ailleurs c'est bizarre car aucun tracé n'est fermé vu que le nom est
sur le tracé


ce ne sont que des relations

Cordialement
--
David Crochet

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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

Ok David merci pour l'info

Le 15 octobre 2014 13:22, David Crochet david.croc...@free.fr a écrit :

 Bonjour

 Le 15/10/2014 11:05, Jérôme Seigneuret a écrit :

 d'ailleurs c'est bizarre car aucun tracé n'est fermé vu que le nom est
 sur le tracé


 ce ne sont que des relations

 Cordialement
 --
 David Crochet


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

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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

Non justement car ce sont bien tout un tas de relations administratives de
niveau 10 qui ont été créées toutes correctement fermées sauf une en cours
de tracé visiblement avec un chemin isolé de toute relations car
visiblement il manque des traits a l'est pour ne pas reprendre les
parcelles d'une voirie de jonction. Et id n'y est pour rien car chacune des
relations administratives des noms représentant selon les cas un lieu dit,
une rue, une place, ou presque tout un quartier... Et ce sont des groupes
de parcelles couvrant des propriétés différentes et des petites voiries de
desserte interne. Bref ca a été fait volontairement et sans aucun rapport
avec les landuse même si pour certaines relations (en minorité) il y a des
wommns avec les landuse. Bref je ne comprend pas sur quoi se base ce
découpage qui n plus est incomplet au nord ouest de la commune.

Ne regarde pas que le way que j'ai indique mais les ways qui y sont
connecte par les extrémités. Un requête overpass sur les admin level 10
dans une BBox couvrant la commune et tu comprendras mieux.

NB: c'est toi qui a créé ces relations?
 Le 15 oct. 2014 11:06, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :

 Les zones dont tu parles pour moi c'est pas du boundary, c'est du
 découpage cadastre des lieu-dits (voisinage dans un village ou quartier en
 ville ou hameau) En principe moi je fais juste un noeud toponyme mais on
 peu faire des zones toponymes et faire le lien vers le nom du contour
 administratif en question. d'ailleurs c'est bizarre car aucun tracé n'est
 fermé vu que le nom est sur le tracé

 on peut mettre un is_in=* pour lier avec le boundary de la commune
 certains font des landuse= residential mais je trouve ça pourri pour
  faire des toponymes. Moi je préfère juste faire comme ici :
 http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
 dans le polygone mais sur un noeud et les lier si besoin...(il y a
 peut-être mieux)

 Le landuse est un autre objet pour moi. Mais je vais pas revenir sur ça
 c'est pas le sujet.

 Pour réparer moi je fais ça dans JOSM en important que le tronçon boundary
 en question par son id et en important uniquement les relations. Après en
 cas de problèmes JOSM demande de corriger les incohérence avant de faire la
 sauvegarde. J'avais fait une connerie de ce type sur Montpellier. J'ai
 juste refermé le way et fini.

 En même temps iD fou un peu la merde:
  Si tu coupes un polygon pour en faire deux il coupe toute les relations
 et ça ressemble un peu à ce que tu présentes.




 Le 15 octobre 2014 10:14, Philippe Verdy verd...@wanadoo.fr a écrit :

 En tentant de corriger des erreurs de frontières incomplètes dans Osmose,
 je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans ce qui ne
 ,e semble pas être des quartiers mais des noms de parcelles (ou groupes de
 parcelles). Y compris des parcelles homonymes et limitrophes l'une de
 l'autre.
 Les noms sont parfois des lieux-dits, ou des noms de rues.

 Exemple autour de ceci:

 http://www.openstreetmap.org/way/306246629

 Le chemin est isolé mais la frontière n'est pas fermée (il n'est encore
 dans aucune relation mais a déjà un tag admin_level 10), et la commune
 n'est visiblement pas entièrement découpée, je ne vois pas comment corriger
 ces relations administrative pour les fermer correctement, et comment les
 retaguer correctement si ce n'est pas administratif.

 Pour l'instant je n'ai rien supprimé (ce tracé est tout demême complexe
 pour une seule commune), juste levé quelques anomalies géométriques pour
 vérifier la cohérence de ce découpage dont la classification reste tout de
 même à revoir si on doit garder ce découpage pour une certaine utilité (il
 ne me semble pas qu'il soi approprié pour les lieux-dits). Je me demande
 d'où ce découpage est issu : est-ce que c'est le découpage des zones
 cadastrales ? L'auteur comptait-il poursuivre ensuite avec les parcelles
 individuelles ?

 Jusqu'à présent on utilisait le niveau 9 pour les arrondissements de
 Paris Lyon Marseille o pour les communes associées au sein d'une même
 commune; le niveau 10 pour des quartiers réels, mais pas pour un découpage
 quasi parcellaire comme ici.

 Note: je ne m'adresse pas spécifiquement à cet auteur (il peut
 s'exprimer; je ne lui tape pas dessus et il peut avoir des intentions
 louables), si sur le fait que ce découpage soit incomplet, mais juste sur
 la question de la pertinence de ces données (pérennité, adéquation à une
 utilisation par exemple pour des plans immobiliers) et surtout de leur
 classification, pour que cela ne nuise pas aux autres utilisations des
 données (j'ai peur que ça pollue les recherches de Nominatim par exemple,
 ou que cela nuise à la recherche d'adresses et lieux-dits, liée au projet
 BANO).

 Le risque de conserver ce découpage au niveau admin 10 c'est la confusion
 qui pourrait naitre du fait de l'association de communes voisines, ou d'une
 réelle division administrative pour les services intercommunaux (comme

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

Tu poses la question à David je suppose pour les relations. Perso j'en fait
quasiment jamais. Je vais essayer la requête overpass pour voir et mieux
comprendre.

Le 15 octobre 2014 13:45, Philippe Verdy verd...@wanadoo.fr a écrit :

 Non justement car ce sont bien tout un tas de relations administratives de
 niveau 10 qui ont été créées toutes correctement fermées sauf une en cours
 de tracé visiblement avec un chemin isolé de toute relations car
 visiblement il manque des traits a l'est pour ne pas reprendre les
 parcelles d'une voirie de jonction. Et id n'y est pour rien car chacune des
 relations administratives des noms représentant selon les cas un lieu dit,
 une rue, une place, ou presque tout un quartier... Et ce sont des groupes
 de parcelles couvrant des propriétés différentes et des petites voiries de
 desserte interne. Bref ca a été fait volontairement et sans aucun rapport
 avec les landuse même si pour certaines relations (en minorité) il y a des
 wommns avec les landuse. Bref je ne comprend pas sur quoi se base ce
 découpage qui n plus est incomplet au nord ouest de la commune.

 Ne regarde pas que le way que j'ai indique mais les ways qui y sont
 connecte par les extrémités. Un requête overpass sur les admin level 10
 dans une BBox couvrant la commune et tu comprendras mieux.

 NB: c'est toi qui a créé ces relations?
  Le 15 oct. 2014 11:06, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
 écrit :

 Les zones dont tu parles pour moi c'est pas du boundary, c'est du
 découpage cadastre des lieu-dits (voisinage dans un village ou quartier en
 ville ou hameau) En principe moi je fais juste un noeud toponyme mais on
 peu faire des zones toponymes et faire le lien vers le nom du contour
 administratif en question. d'ailleurs c'est bizarre car aucun tracé n'est
 fermé vu que le nom est sur le tracé

 on peut mettre un is_in=* pour lier avec le boundary de la commune
 certains font des landuse= residential mais je trouve ça pourri pour
  faire des toponymes. Moi je préfère juste faire comme ici :
 http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
 dans le polygone mais sur un noeud et les lier si besoin...(il y a
 peut-être mieux)

 Le landuse est un autre objet pour moi. Mais je vais pas revenir sur ça
 c'est pas le sujet.

 Pour réparer moi je fais ça dans JOSM en important que le tronçon
 boundary en question par son id et en important uniquement les relations.
 Après en cas de problèmes JOSM demande de corriger les incohérence avant de
 faire la sauvegarde. J'avais fait une connerie de ce type sur Montpellier.
 J'ai juste refermé le way et fini.

 En même temps iD fou un peu la merde:
  Si tu coupes un polygon pour en faire deux il coupe toute les relations
 et ça ressemble un peu à ce que tu présentes.




 Le 15 octobre 2014 10:14, Philippe Verdy verd...@wanadoo.fr a écrit :

 En tentant de corriger des erreurs de frontières incomplètes dans
 Osmose, je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans
 ce qui ne ,e semble pas être des quartiers mais des noms de parcelles (ou
 groupes de parcelles). Y compris des parcelles homonymes et limitrophes
 l'une de l'autre.
 Les noms sont parfois des lieux-dits, ou des noms de rues.

 Exemple autour de ceci:

 http://www.openstreetmap.org/way/306246629

 Le chemin est isolé mais la frontière n'est pas fermée (il n'est encore
 dans aucune relation mais a déjà un tag admin_level 10), et la commune
 n'est visiblement pas entièrement découpée, je ne vois pas comment corriger
 ces relations administrative pour les fermer correctement, et comment les
 retaguer correctement si ce n'est pas administratif.

 Pour l'instant je n'ai rien supprimé (ce tracé est tout demême complexe
 pour une seule commune), juste levé quelques anomalies géométriques pour
 vérifier la cohérence de ce découpage dont la classification reste tout de
 même à revoir si on doit garder ce découpage pour une certaine utilité (il
 ne me semble pas qu'il soi approprié pour les lieux-dits). Je me demande
 d'où ce découpage est issu : est-ce que c'est le découpage des zones
 cadastrales ? L'auteur comptait-il poursuivre ensuite avec les parcelles
 individuelles ?

 Jusqu'à présent on utilisait le niveau 9 pour les arrondissements de
 Paris Lyon Marseille o pour les communes associées au sein d'une même
 commune; le niveau 10 pour des quartiers réels, mais pas pour un découpage
 quasi parcellaire comme ici.

 Note: je ne m'adresse pas spécifiquement à cet auteur (il peut
 s'exprimer; je ne lui tape pas dessus et il peut avoir des intentions
 louables), si sur le fait que ce découpage soit incomplet, mais juste sur
 la question de la pertinence de ces données (pérennité, adéquation à une
 utilisation par exemple pour des plans immobiliers) et surtout de leur
 classification, pour que cela ne nuise pas aux autres utilisations des
 données (j'ai peur que ça pollue les recherches de Nominatim par exemple,
 ou que cela nuise à la recherche d'adresses et

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

Layers en fait d'ailleurs un rendu de toutes ces relations qui sont bien là

http://layers.openstreetmap.fr/?zoom=13lat=48.58094lon=-0.35914layers=BFFFTFF

Il n'y a qu'un seul way qui ne correspond encore à aucune relation 10 bien
qu'il soit marqué comme boundary de niveau 10 et ce way est connecté
correctement par ses extrémités aux autres utilisés par des relations
boundary de niveau 10.

D'ailleurs je vois que depuis mon premier message il y a eu de nouvelles
relations ajoutées pour les lieux-dits. Mais certains leiux-dits sont
coupés en deux (La Sourdière par exemple) et pas du tout par l'ajout d'une
limite de landuse et je ne vois pas pourquoi iD découperait une relation en
deux relations. du fait qu'on découpe un segment, il a plutôt tendance à
accumuler les ways découpés dans les relations existantes et y laisser des
ways en trop...




Le 15 octobre 2014 13:45, Philippe Verdy verd...@wanadoo.fr a écrit :

 Non justement car ce sont bien tout un tas de relations administratives de
 niveau 10 qui ont été créées toutes correctement fermées sauf une en cours
 de tracé visiblement avec un chemin isolé de toute relations car
 visiblement il manque des traits a l'est pour ne pas reprendre les
 parcelles d'une voirie de jonction. Et id n'y est pour rien car chacune des
 relations administratives des noms représentant selon les cas un lieu dit,
 une rue, une place, ou presque tout un quartier... Et ce sont des groupes
 de parcelles couvrant des propriétés différentes et des petites voiries de
 desserte interne. Bref ca a été fait volontairement et sans aucun rapport
 avec les landuse même si pour certaines relations (en minorité) il y a des
 wommns avec les landuse. Bref je ne comprend pas sur quoi se base ce
 découpage qui n plus est incomplet au nord ouest de la commune.

 Ne regarde pas que le way que j'ai indique mais les ways qui y sont
 connecte par les extrémités. Un requête overpass sur les admin level 10
 dans une BBox couvrant la commune et tu comprendras mieux.

 NB: c'est toi qui a créé ces relations?
  Le 15 oct. 2014 11:06, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
 écrit :

 Les zones dont tu parles pour moi c'est pas du boundary, c'est du
 découpage cadastre des lieu-dits (voisinage dans un village ou quartier en
 ville ou hameau) En principe moi je fais juste un noeud toponyme mais on
 peu faire des zones toponymes et faire le lien vers le nom du contour
 administratif en question. d'ailleurs c'est bizarre car aucun tracé n'est
 fermé vu que le nom est sur le tracé

 on peut mettre un is_in=* pour lier avec le boundary de la commune
 certains font des landuse= residential mais je trouve ça pourri pour
  faire des toponymes. Moi je préfère juste faire comme ici :
 http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
 dans le polygone mais sur un noeud et les lier si besoin...(il y a
 peut-être mieux)

 Le landuse est un autre objet pour moi. Mais je vais pas revenir sur ça
 c'est pas le sujet.

 Pour réparer moi je fais ça dans JOSM en important que le tronçon
 boundary en question par son id et en important uniquement les relations.
 Après en cas de problèmes JOSM demande de corriger les incohérence avant de
 faire la sauvegarde. J'avais fait une connerie de ce type sur Montpellier.
 J'ai juste refermé le way et fini.

 En même temps iD fou un peu la merde:
  Si tu coupes un polygon pour en faire deux il coupe toute les relations
 et ça ressemble un peu à ce que tu présentes.




 Le 15 octobre 2014 10:14, Philippe Verdy verd...@wanadoo.fr a écrit :

 En tentant de corriger des erreurs de frontières incomplètes dans
 Osmose, je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans
 ce qui ne ,e semble pas être des quartiers mais des noms de parcelles (ou
 groupes de parcelles). Y compris des parcelles homonymes et limitrophes
 l'une de l'autre.
 Les noms sont parfois des lieux-dits, ou des noms de rues.

 Exemple autour de ceci:

 http://www.openstreetmap.org/way/306246629

 Le chemin est isolé mais la frontière n'est pas fermée (il n'est encore
 dans aucune relation mais a déjà un tag admin_level 10), et la commune
 n'est visiblement pas entièrement découpée, je ne vois pas comment corriger
 ces relations administrative pour les fermer correctement, et comment les
 retaguer correctement si ce n'est pas administratif.

 Pour l'instant je n'ai rien supprimé (ce tracé est tout demême complexe
 pour une seule commune), juste levé quelques anomalies géométriques pour
 vérifier la cohérence de ce découpage dont la classification reste tout de
 même à revoir si on doit garder ce découpage pour une certaine utilité (il
 ne me semble pas qu'il soi approprié pour les lieux-dits). Je me demande
 d'où ce découpage est issu : est-ce que c'est le découpage des zones
 cadastrales ? L'auteur comptait-il poursuivre ensuite avec les parcelles
 individuelles ?

 Jusqu'à présent on utilisait le niveau 9 pour les arrondissements de
 Paris Lyon Marseille o

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

Le découpage n'est visiblement pas fait n'importe comment, les noms sont
cohérents avec les noms des lieux place=* pour les lieux-dits, ou avec
certains équipements communaux (le stade)

Le tracé n'est pas non plus issu d'un import cadastral direct. C'est un
microzonage de la commune.

A mon avis la source (non indiquée) doit être un PLU (plan local
d'urbanisme), sans doute un PDF publié par la commune, retracé à la main en
sa basant sur l'imagerie Bing ou avec un fond de carte Mapnik (il est assez
précis dans la géolocalisation des noeuds, mais il est fait réemlement
indépendamment des traits des landuse ou ceux des rues ou voies communales
ou petits chemins ruraux.

Je vous très mal créer ce découpage dans iD et ne pas se mélanger les
pinceaux car il n'y a pas d'incohérence, juste un seul trait isolé pour un
polygone qui n'était pas complet, comme si le travail avait été laissé en
cours.

Noter aussi qu'il y a deux pièces nommés selon le lieu-dit Le Rocher
Broutin, la plus grande au sud n'est faite presque que de forêt, mais la
forêt déborde un peu au nord sur la pièce homonyme (la séparation
correspond à peu près à un peut chemin forestier et un ruisseau longé par
ce chemin), et un peu sur une autre pièce couvrant le lieu-dit La
Bigotière (là encore en suivant à peu près un chemin forestier)

Les tracés de landuse sont plutôt pas mal faits (on est loin de l'import
CORINE dont il n'est même plus question ici), même si un peu plus de
précision pourrait encore être ajouté (soit sur ce tracé admin, soit sur
les chemins et rues) Le tracé évite convenablement de couper des bâtiments
en 2.

Mais ma question essentielle est : est-ce bien du niveau administratif 10 ?
En tout cas cela ne correspond pas exactement aux lieux-dits (certains
lieux dits sont groupés, d'autres sont découpés en 2 ou 3 pièces
adjascentes) et cela laisse suggérer justement que c'est basé sur un PLU.

Voire peut-être des IRIS, la commune étant assez peuplée pour avoir un tel
découpage; avec des pièces très petites dans les zones les plus densément
habitées - peu importe si ça découpe un lieu-dit - et très grandes pour les
zones de forêt ou grands champs agricoles (dans lesquels il y a inclus
dedans les zones habitées, des fermes, ou petits lotissements).

Le zonage en IRIS étant utile pour répartir les électeurs sur les listes
des bureaux de vote (indépendamment du lieu de vote qui regroupe pluseurs
bureaux souvent dans la même salle) en assemblant les électeurs attribués
sur chaque IRIS pour constituer les listes avec le quorum idéal qui
facilite le dépouillement (environ 400 électeurs inscrits ou un peu moins)
et évite de devoir recruter trop d'assesseurs (au delà du seul personnel
communal qui doit être présent au moins dans le lieu de rassemblement des
bureaux de vote avec au moins 2 personnes qui doivent rester présentes
durant toute la durée du scrutin, avec les électeurs volontaires qui se
présentent) Mais là le découpage est visiblement trop fin pour suffire à
constituer une liste électorale pour un bureau de vote, il y a beaucoup
trop de pièces par rapport à la population communale (je n'ai pas regardé
le nombre d'inscrits qui est plus petit)

Bref je ne critique pas le travail fait mais je doute que soit les bons
tags (et ce tracé ne fait pas doublon avec les lieux-dits en noeuds place=*
qui sont à part et pas liés directement). Dommage qu'il n'y ait pas la
source pour savoir à quoi il correspond exactement. Si pas de réponse de la
part de l'auteur, il va falloir consulter le site de la mairie, il y a
peut-être un document publié qui montre ce découpage (même s'il est encore
incomplet mais bien avancé).

Le 15 octobre 2014 13:53, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :

 Tu poses la question à David je suppose pour les relations. Perso j'en
 fait quasiment jamais. Je vais essayer la requête overpass pour voir et
 mieux comprendre.

 Le 15 octobre 2014 13:45, Philippe Verdy verd...@wanadoo.fr a écrit :

 Non justement car ce sont bien tout un tas de relations administratives de
 niveau 10 qui ont été créées toutes correctement fermées sauf une en cours
 de tracé visiblement avec un chemin isolé de toute relations car
 visiblement il manque des traits a l'est pour ne pas reprendre les
 parcelles d'une voirie de jonction. Et id n'y est pour rien car chacune des
 relations administratives des noms représentant selon les cas un lieu dit,
 une rue, une place, ou presque tout un quartier... Et ce sont des groupes
 de parcelles couvrant des propriétés différentes et des petites voiries de
 desserte interne. Bref ca a été fait volontairement et sans aucun rapport
 avec les landuse même si pour certaines relations (en minorité) il y a des
 wommns avec les landuse. Bref je ne comprend pas sur quoi se base ce
 découpage qui n plus est incomplet au nord ouest de la commune.

 Ne regarde pas que le way que j'ai indique mais les ways qui y sont
 connecte par les extrémités. Un requête overpass sur les admin level 10
 dans une BBox

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

http://overpass-turbo.eu/s/5tq une requete des way en question.
http://overpass-turbo.eu/s/5tv une requete des relation en question.

Il y a des trous dans les relations et je pense qu'il manque des tronçon
pour fermer le tout.

Sinon j'ai regardé le cadastre pour voir et c'est un regroupement de
parcelle correspondant au lieu-dit (voir sur cadastre.gouv.fr)
Un centre serait pas mal pour voir les nom des quartiers dans les relation.


Pour le reste en effet sous iD si tu veux découper un way il faut déjà
vérifier s'il n'est pas en relation avec un autre tracé au moment de faire
le découpage sur le noeud souhaité.Une route superposé sur un découpage
administratif (les noeud sont en relation par exemple) si tu découpes le
noeud avec des relations, ça coupe tous les objets concernées par ce noeud.

Et ça tu ne le sait pas forcément. Si tu as plusieurs niveaux de contours
administratif c'est la même merde.  Le seul moyen que j'ai trouvé c'est de
décomposer la relation au préalable puis couper l'entité puis refaire la
relation si nécessaire.

C'est en coupant une route que j'avais tous cassé la dernière fois.

Je regarde le cadastre pour vérifier ta zone




Le 15 octobre 2014 13:55, Philippe Verdy verd...@wanadoo.fr a écrit :

 Layers en fait d'ailleurs un rendu de toutes ces relations qui sont bien là


 http://layers.openstreetmap.fr/?zoom=13lat=48.58094lon=-0.35914layers=BFFFTFF

 Il n'y a qu'un seul way qui ne correspond encore à aucune relation 10 bien
 qu'il soit marqué comme boundary de niveau 10 et ce way est connecté
 correctement par ses extrémités aux autres utilisés par des relations
 boundary de niveau 10.

 D'ailleurs je vois que depuis mon premier message il y a eu de nouvelles
 relations ajoutées pour les lieux-dits. Mais certains leiux-dits sont
 coupés en deux (La Sourdière par exemple) et pas du tout par l'ajout d'une
 limite de landuse et je ne vois pas pourquoi iD découperait une relation en
 deux relations. du fait qu'on découpe un segment, il a plutôt tendance à
 accumuler les ways découpés dans les relations existantes et y laisser des
 ways en trop...




 Le 15 octobre 2014 13:45, Philippe Verdy verd...@wanadoo.fr a écrit :

 Non justement car ce sont bien tout un tas de relations administratives de
 niveau 10 qui ont été créées toutes correctement fermées sauf une en cours
 de tracé visiblement avec un chemin isolé de toute relations car
 visiblement il manque des traits a l'est pour ne pas reprendre les
 parcelles d'une voirie de jonction. Et id n'y est pour rien car chacune des
 relations administratives des noms représentant selon les cas un lieu dit,
 une rue, une place, ou presque tout un quartier... Et ce sont des groupes
 de parcelles couvrant des propriétés différentes et des petites voiries de
 desserte interne. Bref ca a été fait volontairement et sans aucun rapport
 avec les landuse même si pour certaines relations (en minorité) il y a des
 wommns avec les landuse. Bref je ne comprend pas sur quoi se base ce
 découpage qui n plus est incomplet au nord ouest de la commune.

 Ne regarde pas que le way que j'ai indique mais les ways qui y sont
 connecte par les extrémités. Un requête overpass sur les admin level 10
 dans une BBox couvrant la commune et tu comprendras mieux.

 NB: c'est toi qui a créé ces relations?
  Le 15 oct. 2014 11:06, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
 écrit :

 Les zones dont tu parles pour moi c'est pas du boundary, c'est du
 découpage cadastre des lieu-dits (voisinage dans un village ou quartier en
 ville ou hameau) En principe moi je fais juste un noeud toponyme mais on
 peu faire des zones toponymes et faire le lien vers le nom du contour
 administratif en question. d'ailleurs c'est bizarre car aucun tracé n'est
 fermé vu que le nom est sur le tracé

 on peut mettre un is_in=* pour lier avec le boundary de la commune
 certains font des landuse= residential mais je trouve ça pourri pour
  faire des toponymes. Moi je préfère juste faire comme ici :
 http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
 dans le polygone mais sur un noeud et les lier si besoin...(il y a
 peut-être mieux)

 Le landuse est un autre objet pour moi. Mais je vais pas revenir sur ça
 c'est pas le sujet.

 Pour réparer moi je fais ça dans JOSM en important que le tronçon
 boundary en question par son id et en important uniquement les relations.
 Après en cas de problèmes JOSM demande de corriger les incohérence avant de
 faire la sauvegarde. J'avais fait une connerie de ce type sur Montpellier.
 J'ai juste refermé le way et fini.

 En même temps iD fou un peu la merde:
  Si tu coupes un polygon pour en faire deux il coupe toute les relations
 et ça ressemble un peu à ce que tu présentes.




 Le 15 octobre 2014 10:14, Philippe Verdy verd...@wanadoo.fr a écrit :

 En tentant de corriger des erreurs de frontières incomplètes dans
 Osmose, je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans
 ce qui ne ,e semble

Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien

2014-10-15 Thread Pieren

2014-10-14 22:37 GMT+02:00 Vincent de Château-Thierry osm.v...@free.fr:

 L'idée est de petit à petit gagner en homogénéité sur la manière de tagguer
 un multipolygon. Jusque là, c'est souvent le(s) ways avec le rôle outer qui
 portaient les tags décrivant en fait tout le multipolygon. Le warning est
 une incitation à transférer ces tags directement au niveau de la relation :
 plus cohérent en modélisation, et du coup plus simple à interpréter par les
 logiciels clients comme osm2pgsql.

Je trouve que c'est une erreur parce que maintenant on crée une
nouvelle incohérence. Pour quelqu'un qui trace par exemple des
buildings, il met le tag building=yes sur le way du polygone. Par
contre, pour les buildings avec trous, le tag disparait du outer
way, uniquement parce qu'il a fallut créer une relation multipolygon.

Pieren

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

Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien

2014-10-15 Thread Pierre-Yves Berrard

Le 15 octobre 2014 14:55, Pieren pier...@gmail.com a écrit :

 2014-10-14 22:37 GMT+02:00 Vincent de Château-Thierry osm.v...@free.fr:

  L'idée est de petit à petit gagner en homogénéité sur la manière de
 tagguer
  un multipolygon. Jusque là, c'est souvent le(s) ways avec le rôle outer
 qui
  portaient les tags décrivant en fait tout le multipolygon. Le warning est
  une incitation à transférer ces tags directement au niveau de la
 relation :
  plus cohérent en modélisation, et du coup plus simple à interpréter par
 les
  logiciels clients comme osm2pgsql.

 Je trouve que c'est une erreur parce que maintenant on crée une
 nouvelle incohérence. Pour quelqu'un qui trace par exemple des
 buildings, il met le tag building=yes sur le way du polygone. Par
 contre, pour les buildings avec trous, le tag disparait du outer
 way, uniquement parce qu'il a fallut créer une relation multipolygon.

 Pieren


Je ne vois pas où est l'incohérence.
Le building est l'élément comportant le trou, donc la relation.
C'est donc sur elle que les tags doivent être mis.

Mettre le tag sur l'outer seulement signifie que le trou fait partie du
bâtiment.

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

Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien

2014-10-15 Thread Romain MEHUT

Le 15 octobre 2014 15:10, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
 a écrit :


  Je ne vois pas où est l'incohérence.
 Le building est l'élément comportant le trou, donc la relation.
 C'est donc sur elle que les tags doivent être mis.

 Mettre le tag sur l'outer seulement signifie que le trou fait partie du
 bâtiment.


Un exemple des 2 cas de figure car je ne suis pas sûr de bien comprendre?

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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

2014-10-15 Thread Christian Quest

Mouais... ces relations ont été générées comment ?

C'est normal d'en avoir trois qui se touchent et qui portent le même nom ?

Je ne suis pas vraiment fan du admin_level=10 car on ne peut vraiment pas
comparer un lieu dit de quelques parcelles cultivées avec un quartier de
Paris bien identifié, qui a un comité de quartier et tout le bazar associé.

Ca ressemble plus à des place=locality mais surfaciques au lieu des
habituels ponctuels.

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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

Il y a bien un PLU à la Ferté Macé (publié en annonce légale dans
Ouest-France, 1,60€ sur https://actulegales.fr/annonce-legale/1004035453).
Mais il va sans doute être obsolète car la commune souhaite s'associer avec
les autres communes de la communauté de communes pour passer au PLUi
(intercommunal).

Je ne comprend pas trop comment tu manipules les choses sous iD mais je
n'ai jamais vu avoir besoin de couper une relation en deux et copier des
morceaux pour ensuite reconsituer la zone initiale en réassemblant après
avoir découpé une route.

Je naime pas du tout iD pour faire des découpages complexes de toute façon
JOSM est tellement plus pratique, plus souple et permet de ne pas être noyé
sous das tas d'autres données. iD c'est fait pour des modifs très locales
(pas pus grande qu'une seule rue, ou ajouter un batiment, une adresse, un
nom; une limite de vitesse, un passage piéton.

iD est une catastrophe pour ceux qui l'ont utilisé pour ajouter des
rond-points (en cassant des lignes de bus; et autres itinéraires dans
lesquels se forment des trous. iD mélange aussi tous les membres et ne
garde pas leur continuité, il coute cher ensuite pour ceux qui doivent
réparer. Je connais très peu de gens capables de comprendre comment
travailler efficacement avec des relations dans cet éditeur. Et puis
qu'est-ce que c'est lent et lourd en mémoire, le navigateur rame, les accès
constants au réseau sont pénibles, même sur une connexion fibre. A ,on avis
il surcharge même les serveurs de l'API d'OSM.

La manipulation des relations dans iD passe par des dialogues de sélection
ultra compliqués et très lourds car peu sélectifs, il faut sans cesse
passer en revue les longues listes proposées et ne pas se tromper car il y
a peu d'indice et aucun filtrage. Il est inutilisable pour moi en dessous
du niveau de zoom 15; donc pas moyen de travailler dessus à l'échelle d'une
commune entière comme la Ferté-Macé (c'est illisible en plus; on a baucoup
de mal à sélectionner ce qu'on veut avec).

iD c'est de l'occasionnel quand j'ai déjà une session OSM en cours et pas
envie de charger une autre calque. Parfois pour des modifs très légères
(par exemple corrections très simples dans OSMose sur un seul objet)
j'utilise directement rawedit (en XML) c'est plus vite fait, mais jamais je
n'utiliserai iD (ni même Potlatch2) pour Osmose, si possible j'utilise JOSM
pour tout (je peux provoirement cacher un calque et ouvrir un calque séparé
pour des modifs ponctuelles qui nécessitent plus de données que ce que je
ne veux pas garder dans le calque actuel si je ne veux pas ensuite purger
des tas d'éléments non modifiés et non utiles à la correction à faire).

JOSM est mon ami (avec les touches CLTR+ALT+D ou une icone ajoutée sur la
barre d'icônes pour la même commande, plus pratique d'un clic qu'avec 3
touches). Il permet aussi de créer temporairement des relations de travail
pour garder des sélections d'objets en cours de modif ou à vérifier. Pour
repérer facilement cette relation de travail dans la liste, je lui donne un
tag type=!TODO au lieu de multipolygon, avec un point d'exclamation au
début de la valeur pour qu'elle soit en tête de liste des relations (qui
est classée par type puis par nom).

Modifs terminées, je peux sauvegarder le fichier, purger la relation
temporaire de la mémoire et je peux envoyer les données puis fusionner les
données dans un calque principal pour le mettre à jour avec les données que
je souhaite garder pour la suite.

Le 15 octobre 2014 14:55, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :

 http://overpass-turbo.eu/s/5tq une requete des way en question.
 http://overpass-turbo.eu/s/5tv une requete des relation en question.

 Il y a des trous dans les relations et je pense qu'il manque des tronçon
 pour fermer le tout.

 Sinon j'ai regardé le cadastre pour voir et c'est un regroupement de
 parcelle correspondant au lieu-dit (voir sur cadastre.gouv.fr)
 Un centre serait pas mal pour voir les nom des quartiers dans les relation.


 Pour le reste en effet sous iD si tu veux découper un way il faut déjà
 vérifier s'il n'est pas en relation avec un autre tracé au moment de faire
 le découpage sur le noeud souhaité.Une route superposé sur un découpage
 administratif (les noeud sont en relation par exemple) si tu découpes le
 noeud avec des relations, ça coupe tous les objets concernées par ce noeud.

 Et ça tu ne le sait pas forcément. Si tu as plusieurs niveaux de contours
 administratif c'est la même merde.  Le seul moyen que j'ai trouvé c'est de
 décomposer la relation au préalable puis couper l'entité puis refaire la
 relation si nécessaire.

 C'est en coupant une route que j'avais tous cassé la dernière fois.

 Je regarde le cadastre pour vérifier ta zone




 Le 15 octobre 2014 13:55, Philippe Verdy verd...@wanadoo.fr a écrit :

 Layers en fait d'ailleurs un rendu de toutes ces relations qui sont bien là


 http://layers.openstreetmap.fr/?zoom=13lat=48.58094lon=-0.35914layers=BFFFTFF

 Il

Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien

2014-10-15 Thread Nicolas Moyroud

Oui c'est sûr que dans l'esprit ce n'est pas une mauvaise chose dans 
l'idée, mais dans la réalisation c'est une catastrophe. Je veux dire ce 
genre de message cryptique pour un non-initié et en plus non traduit en 
français. Le contributeur moyen qui modifie un simple tag sur un outer 
de multipolygon va se retrouver avec ce baratin qui lui pète à la 
tronche, ne rien comprendre et se barrer en courant de ce repaire de 
geo-geek ! Bon j'exagère un peu hein comme d'habitude, mais n'empêche... 
;-)


Nicolas

-
Nicolas Moyroud
Site web libre@vous : http://libreavous.teledetection.fr
-
« Celui qui croit qu’une croissance infinie peut continuer indéfiniment dans un 
monde fini est soit un fou, soit un économiste. » Kenneth Boulding.

Le 14/10/2014 22:37, Vincent de Château-Thierry a écrit :



Ça date d'il y a quelques jours :
http://josm.openstreetmap.de/changeset/7569/josm

L'idée est de petit à petit gagner en homogénéité sur la manière de 
tagguer un multipolygon. Jusque là, c'est souvent le(s) ways avec le 
rôle outer qui portaient les tags décrivant en fait tout le 
multipolygon. Le warning est une incitation à transférer ces tags 
directement au niveau de la relation : plus cohérent en modélisation, 
et du coup plus simple à interpréter par les logiciels clients comme 
osm2pgsql.


vincent



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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)


Bonjour

Le 15/10/2014 10:14, Philippe Verdy a écrit :

si sur le fait que ce découpage soit incomplet,


Il y a deux choses :
- j'ai pas eu le temps de tous les faire
- il y a des zones non nommées

mais juste sur la

question de la pertinence de ces données (pérennité, adéquation à une
utilisation par exemple pour des plans immobiliers) et surtout de leur
classification,


Dans les découpages administratifs, il y a du politique, de 
ecclésiastique et de l'administratif.

Le niveau 8 représente la commune, soit.
Ensuite il existe un découpage plus fin, les lieux dits et les quartiers.

Certes le niveau 10 définit le découpage des quartiers.

Ici, on est encore plus fin, c'est des lieux-dits
sauf que je m'aide d'outils qui me permettent de travailler sur du 
visuels (layers.osm.fr) je sais, c'est pas bien, mais j'ai pas mieux à 
mon niveau de connaissances et de compétences.


Mais comme je le disais, c'est en travail en cours, il restera à définir 
avec la ville, de nommer des lieux dits qui n'ont pas de noms, et aussi 
de leurs montrer des exclaves dans la commune ou des doublons. Pour les 
doublons, c'est logiques puisque le découpage est lié aux feuilles 
cadastrales. Les zones homonymiques seront logiquement à fusionner. Mais 
a voir avec la commune si c'est réellement le cas.


De même , cela permet de pointer de coquille typographique :
- Loisivière et L'Oisivière


Cordialement
--
David Crochet

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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)


Bonjour

Le 15/10/2014 11:05, Jérôme Seigneuret a écrit :

Moi je préfère juste faire comme ici :
http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le nom
dans le polygone mais sur un noeud et les lier si besoin...(il y a
peut-être mieux)


Oui c'est exactement cette définition que je recherche, mais il n'existe 
pas en tant que relation mais noeud ou chemin.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

Ok, Je suis pas encore familier avec JOSM. J'ai pas pris le temps de m'y
mettre plus que ça. J'ai plus l'habitude des solution web ou d'ArcGIS. Mais
bon, tu as raisons de dire qu''iD que c'est pas l'idéal. Mais bon dans ce
cas il faut limité les possibililé d'iD ou amélioré son fonctionnement pour
éviter des désagréments sans pour autant dire.

Quand tu veux décomposer des intersections, tu et obligé de coupé ton
tronçon et c'est aussi le cas dans JOSM. Avec iD il n'y a pas de filtre et
c'est dommage. Car c'est histoire de relation ne serait pas aussi chiante.

Je viens de réouvrir le cadastre pour ta zone et elle n'a pas de nom dans
le cadastre d'où le trou mais David pourra surement en dire plus. Je pense
qu'il faut voir avec la mairie pour avoir plus de détail. Et je suis pas
sur que le rattachement à une autre commune change de découpage des
quartiers ou ensembles parcellaires.

Je prendrai plus de temps pour JOSM plus tard pour le moment je suis sur
une appli mobil de tracking pour Windows Phone.



Le 15 octobre 2014 15:23, Philippe Verdy verd...@wanadoo.fr a écrit :

 Il y a bien un PLU à la Ferté Macé (publié en annonce légale dans
 Ouest-France, 1,60€ sur https://actulegales.fr/annonce-legale/1004035453).
 Mais il va sans doute être obsolète car la commune souhaite s'associer avec
 les autres communes de la communauté de communes pour passer au PLUi
 (intercommunal).

 Je ne comprend pas trop comment tu manipules les choses sous iD mais je
 n'ai jamais vu avoir besoin de couper une relation en deux et copier des
 morceaux pour ensuite reconsituer la zone initiale en réassemblant après
 avoir découpé une route.

 Je naime pas du tout iD pour faire des découpages complexes de toute
 façon JOSM est tellement plus pratique, plus souple et permet de ne pas
 être noyé sous das tas d'autres données. iD c'est fait pour des modifs très
 locales (pas pus grande qu'une seule rue, ou ajouter un batiment, une
 adresse, un nom; une limite de vitesse, un passage piéton.

 iD est une catastrophe pour ceux qui l'ont utilisé pour ajouter des
 rond-points (en cassant des lignes de bus; et autres itinéraires dans
 lesquels se forment des trous. iD mélange aussi tous les membres et ne
 garde pas leur continuité, il coute cher ensuite pour ceux qui doivent
 réparer. Je connais très peu de gens capables de comprendre comment
 travailler efficacement avec des relations dans cet éditeur. Et puis
 qu'est-ce que c'est lent et lourd en mémoire, le navigateur rame, les accès
 constants au réseau sont pénibles, même sur une connexion fibre. A ,on avis
 il surcharge même les serveurs de l'API d'OSM.

 La manipulation des relations dans iD passe par des dialogues de sélection
 ultra compliqués et très lourds car peu sélectifs, il faut sans cesse
 passer en revue les longues listes proposées et ne pas se tromper car il y
 a peu d'indice et aucun filtrage. Il est inutilisable pour moi en dessous
 du niveau de zoom 15; donc pas moyen de travailler dessus à l'échelle d'une
 commune entière comme la Ferté-Macé (c'est illisible en plus; on a baucoup
 de mal à sélectionner ce qu'on veut avec).

 iD c'est de l'occasionnel quand j'ai déjà une session OSM en cours et pas
 envie de charger une autre calque. Parfois pour des modifs très légères
 (par exemple corrections très simples dans OSMose sur un seul objet)
 j'utilise directement rawedit (en XML) c'est plus vite fait, mais jamais je
 n'utiliserai iD (ni même Potlatch2) pour Osmose, si possible j'utilise JOSM
 pour tout (je peux provoirement cacher un calque et ouvrir un calque séparé
 pour des modifs ponctuelles qui nécessitent plus de données que ce que je
 ne veux pas garder dans le calque actuel si je ne veux pas ensuite purger
 des tas d'éléments non modifiés et non utiles à la correction à faire).

 JOSM est mon ami (avec les touches CLTR+ALT+D ou une icone ajoutée sur la
 barre d'icônes pour la même commande, plus pratique d'un clic qu'avec 3
 touches). Il permet aussi de créer temporairement des relations de travail
 pour garder des sélections d'objets en cours de modif ou à vérifier. Pour
 repérer facilement cette relation de travail dans la liste, je lui donne un
 tag type=!TODO au lieu de multipolygon, avec un point d'exclamation au
 début de la valeur pour qu'elle soit en tête de liste des relations (qui
 est classée par type puis par nom).

 Modifs terminées, je peux sauvegarder le fichier, purger la relation
 temporaire de la mémoire et je peux envoyer les données puis fusionner les
 données dans un calque principal pour le mettre à jour avec les données que
 je souhaite garder pour la suite.

 Le 15 octobre 2014 14:55, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
 écrit :

 http://overpass-turbo.eu/s/5tq une requete des way en question.
 http://overpass-turbo.eu/s/5tv une requete des relation en question.

 Il y a des trous dans les relations et je pense qu'il manque des tronçon
 pour fermer le tout.

 Sinon j'ai regardé le cadastre pour voir et c'est un regroupement de

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)


Bonjour

Le 15/10/2014 13:45, Philippe Verdy a écrit :

Bref je ne comprend pas sur quoi se base ce découpage


les lieux-dits du Cadastre

qui n plus est

incomplet au nord ouest de la commune.


car je n'ai que 24 par jour et je bosse IRL, donc désolé de ne pouvoir 
faire modifier l'espace-temps à ma guise.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

Mon hypothèse est celle du PLU. Les noms ne sont pas au hasard, on les voit
un peu partout cités (sans carte complète) dans les publications de la
mairie.

Je suppute que a source est soit une consultation visuelle du PLU, soit
directement un utilisateur du SIG communal, et qui importe comme il peut ce
qu'il voit et tente d'adapter à OSM. Je ne suis pas convincu que ce soit la
notion de quartier dans la commune; les zones sont individuellement très
peu peuplées, mais correspondent un peu aux lotissements (plus les terrains
agricoles environnants), des propriétés privées importantes peuvent être
découpées (exemple un camping ou le golf constitué par acquisition de
parcelles successives dans plusieurs zones), mais pas les équipements
communaux (écoles, stade, centres d'activité, services sociaux), et le lac
est tout entier rattaché avec ses berges, un petits bois attenant et un
lotissement tout au nord dans la même pièce.

Il y a une bonne cohérence dans ce découpage au vu des autres données
présentes. Pour l'instant je cherche mais je n'ai pas trouvé de source pour
le PLU communal actuel (ne parlons pas du PLUi envisagé)

Concernant le cadastre j'ai beaucoup de mal à le lire (mais surtout je
n'aime pas du tout ses projections tordues qui ne collent pas avec les
projections WGS84 de l'imagerie et qui déforment tout, et ont des gros
défauts d'affichage et demande un plugin JOSM assez bancal, qui oblige même
à redémarrer JOSM à tout bout de champ...).

Certains sont habitués, mais je ne m'y fais pas du tout à ce
Lambert-multizone franco-français, d'autant plus qu'il n'y a même pas de
conflation avec les communes voisines (ça pose des questions sur les
limites intercommunales..) non rapprochées.

Le 15 octobre 2014 15:21, Christian Quest cqu...@openstreetmap.fr a écrit
:

 Mouais... ces relations ont été générées comment ?

 C'est normal d'en avoir trois qui se touchent et qui portent le même nom ?


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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)


Bonjour

Le 15/10/2014 14:35, Philippe Verdy a écrit :

est-ce bien du niveau administratif 10 ?


Non, mais faute de mieux, je prends cette approche

 En tout cas cela ne correspond

pas exactement aux lieux-dits (certains lieux dits sont groupés,
d'autres sont découpés en 2 ou 3 pièces adjascentes) et cela laisse
suggérer justement que c'est basé sur un PLU.


Car les leiux dits, bien qu'ils portent le même nom sont sur deux 
feuilles cadastrales différentes, dont leurs noms est dupliqués d'autant.


Cordialement


--
David Crochet

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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)


Bonjour

Le 15/10/2014 15:21, Christian Quest a écrit :

ces relations ont été générées comment ?


Depuis les limites cadastrales des lieux-dits

Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)


Bonjour

Le 15/10/2014 15:21, Christian Quest a écrit :

C'est normal d'en avoir trois qui se touchent et qui portent le même nom ?


Même lieu-dit, mais sur plusieurs feuilles cadastrales. L'idée est de 
les fusionner par la suite lorsque l'approche typographique est identique.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)


Bonjour

Le 15/10/2014 14:35, Philippe Verdy a écrit :

Dommage qu'il n'y ait pas la source pour savoir à quoi il correspond
exactemen


Elle est sur le chemin puisque la relations s'appuie sur les chemin : 
Cadastre


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

une zone délimitée peut malgré tout être créée sans nom, ou avec un nom
descriptif qui te semble approprié (avec une note ou FIXME indiquant que le
nom n'est pas officialisé ou n'a pas été trouvé).

Une fois la cohérence du découpage finie, tu pourras changer les tags.

Il n'y a pas que Layers pour en faire le rendu (parfois seulement après
plusieurs jours), Overpass t'en donne un presque instantanément (même si'l
ne vérifie pas tout et peut fermer arbitrairement une zone où il manque un
segment, mais observe comment il change le style de la bordure pour les
segments de fermeture ajoutés automatiquement là où il y a un trou)

Tu peux toujours ajouter du stylage MapCSS dans Overpass, mais je m'en sers
rarement car mes requêtes sont simples et sélectives sur des types d'objet
bien précis.


Le 15 octobre 2014 15:50, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :

 Ok, Je suis pas encore familier avec JOSM. J'ai pas pris le temps de m'y
 mettre plus que ça. J'ai plus l'habitude des solution web ou d'ArcGIS. Mais
 bon, tu as raisons de dire qu''iD que c'est pas l'idéal. Mais bon dans ce
 cas il faut limité les possibililé d'iD ou amélioré son fonctionnement pour
 éviter des désagréments sans pour autant dire.

 Quand tu veux décomposer des intersections, tu et obligé de coupé ton
 tronçon et c'est aussi le cas dans JOSM. Avec iD il n'y a pas de filtre et
 c'est dommage. Car c'est histoire de relation ne serait pas aussi chiante.

 Je viens de réouvrir le cadastre pour ta zone et elle n'a pas de nom dans
 le cadastre d'où le trou mais David pourra surement en dire plus. Je pense
 qu'il faut voir avec la mairie pour avoir plus de détail. Et je suis pas
 sur que le rattachement à une autre commune change de découpage des
 quartiers ou ensembles parcellaires.

 Je prendrai plus de temps pour JOSM plus tard pour le moment je suis sur
 une appli mobil de tracking pour Windows Phone.



 Le 15 octobre 2014 15:23, Philippe Verdy verd...@wanadoo.fr a écrit :

 Il y a bien un PLU à la Ferté Macé (publié en annonce légale dans
 Ouest-France, 1,60€ sur https://actulegales.fr/annonce-legale/1004035453).
 Mais il va sans doute être obsolète car la commune souhaite s'associer avec
 les autres communes de la communauté de communes pour passer au PLUi
 (intercommunal).

 Je ne comprend pas trop comment tu manipules les choses sous iD mais je
 n'ai jamais vu avoir besoin de couper une relation en deux et copier des
 morceaux pour ensuite reconsituer la zone initiale en réassemblant après
 avoir découpé une route.

 Je naime pas du tout iD pour faire des découpages complexes de toute
 façon JOSM est tellement plus pratique, plus souple et permet de ne pas
 être noyé sous das tas d'autres données. iD c'est fait pour des modifs très
 locales (pas pus grande qu'une seule rue, ou ajouter un batiment, une
 adresse, un nom; une limite de vitesse, un passage piéton.

 iD est une catastrophe pour ceux qui l'ont utilisé pour ajouter des
 rond-points (en cassant des lignes de bus; et autres itinéraires dans
 lesquels se forment des trous. iD mélange aussi tous les membres et ne
 garde pas leur continuité, il coute cher ensuite pour ceux qui doivent
 réparer. Je connais très peu de gens capables de comprendre comment
 travailler efficacement avec des relations dans cet éditeur. Et puis
 qu'est-ce que c'est lent et lourd en mémoire, le navigateur rame, les accès
 constants au réseau sont pénibles, même sur une connexion fibre. A ,on avis
 il surcharge même les serveurs de l'API d'OSM.

 La manipulation des relations dans iD passe par des dialogues de
 sélection ultra compliqués et très lourds car peu sélectifs, il faut sans
 cesse passer en revue les longues listes proposées et ne pas se tromper car
 il y a peu d'indice et aucun filtrage. Il est inutilisable pour moi en
 dessous du niveau de zoom 15; donc pas moyen de travailler dessus à
 l'échelle d'une commune entière comme la Ferté-Macé (c'est illisible en
 plus; on a baucoup de mal à sélectionner ce qu'on veut avec).

 iD c'est de l'occasionnel quand j'ai déjà une session OSM en cours et pas
 envie de charger une autre calque. Parfois pour des modifs très légères
 (par exemple corrections très simples dans OSMose sur un seul objet)
 j'utilise directement rawedit (en XML) c'est plus vite fait, mais jamais je
 n'utiliserai iD (ni même Potlatch2) pour Osmose, si possible j'utilise JOSM
 pour tout (je peux provoirement cacher un calque et ouvrir un calque séparé
 pour des modifs ponctuelles qui nécessitent plus de données que ce que je
 ne veux pas garder dans le calque actuel si je ne veux pas ensuite purger
 des tas d'éléments non modifiés et non utiles à la correction à faire).

 JOSM est mon ami (avec les touches CLTR+ALT+D ou une icone ajoutée sur la
 barre d'icônes pour la même commande, plus pratique d'un clic qu'avec 3
 touches). Il permet aussi de créer temporairement des relations de travail
 pour garder des sélections d'objets en cours de modif ou à vérifier. Pour
 repérer

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

Arf ça va trop vite et oui j'ai déjà répondu et dis que cela venait du
cadastre comme David l'a confirmé. Dans OSM on le considère avec des zones
de type place comme j'en parlais mais OSM en zone France permet de faire du
découpage en niveau dix mais les condition varient par pays et en
France *limites
des quartiers utilisés pour la démocracie locale*

*Donc c'est un gros paquet englobant des limites et des zones*

Pour revenir sur le fait qu'une zone porte le même nom c'est aussi possible
mais le cadastre n'efface pas la zone juste elle la renomme ace un petit
coup de blanco

Le 15 octobre 2014 15:58, David Crochet david.croc...@free.fr a écrit :

 Bonjour

 Le 15/10/2014 15:21, Christian Quest a écrit :

 ces relations ont été générées comment ?


 Depuis les limites cadastrales des lieux-dits

 Cordialement

 --
 David Crochet


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

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

[OSM-talk-fr] que faire quand le wiki dit quelques chose de bien mais que c'est mal fait ensuite Was: découpage administratif niveau 10 à la Ferté-Macé (Mayenne)


Bonjour

Lorsque je lis ceci :
http://wiki.openstreetmap.org/wiki/FR:Tag:place=neighbourhood?uselang=fr
c'est exactement ce que je veux faire à la fin.
Sauf que :

La page dit :
- pas de chemin, mais il y en a quand même 5352 d'après la boite 
d'informatiuon TagInfo

- Relation non définie, mais il en existe quand même 1071.

Je fais quoi alors ? Rien ? ben j'ai pas envie car je veux ajouter ces 
infos.

J'ai peut-être tord, je sais pas, mais j'essaie l'essai

comment visualiser si je ne fait pas de bétise ?
Je ne sais utiliser que les rendus. Donc j'utilise temporairement un 
rendu et ensuite si tout va bien, j'étiquette mieux faute de faire bien 
dès le départ.
Donc quel est le mieux faute de bien ? ben c'est un découpage 
administratif puisque le cadastre délimite les zones plus petit que la 
commune, donc j'ai le choix à partir de 9. Donc j'utilise 10, le plus 
petit niveau définit par l'étiquette admin_level.
Et une fois que tout sera fini, je n'aurait plus qu'a rempalcer les 
étiquette des relations en mieux plutôt que mieux faute de bien.


Maintenant si c'est inutile, je ne serai pas vexé.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien

Coté pratique, si je crée un multi polygone  avec 2 outer et un
inner comportant  deux objet dont un avec un trou,  les tag de surfaces
doivent, si j'ai bien compris, se retrouver dans le multi polygone.

tags Multi polygone :

   - landuse = forest
   - leaf_type = broadleaved
   - type = multipolygon

Mais si par exemple les polygones ont un leaf_type différent :

   - leaf_type = mixed
   - leaf_type = broadleaved

Je les place où ces tags ? Je suppose au niveau de chaque polygone et
retirer celui qui à été généré en auto au niveau du multi, c'est cela !

Michel



Le 15 octobre 2014 15:37, Nicolas Moyroud nmoyr...@free.fr a écrit :

 Oui c'est sûr que dans l'esprit ce n'est pas une mauvaise chose dans
 l'idée, mais dans la réalisation c'est une catastrophe. Je veux dire ce
 genre de message cryptique pour un non-initié et en plus non traduit en
 français. Le contributeur moyen qui modifie un simple tag sur un outer de
 multipolygon va se retrouver avec ce baratin qui lui pète à la tronche, ne
 rien comprendre et se barrer en courant de ce repaire de geo-geek ! Bon
 j'exagère un peu hein comme d'habitude, mais n'empêche... ;-)

 Nicolas

 -
 Nicolas Moyroud
 Site web libre@vous : http://libreavous.teledetection.fr
 -
 « Celui qui croit qu’une croissance infinie peut continuer indéfiniment
 dans un monde fini est soit un fou, soit un économiste. » Kenneth Boulding.

 Le 14/10/2014 22:37, Vincent de Château-Thierry a écrit :



 Ça date d'il y a quelques jours :
 http://josm.openstreetmap.de/changeset/7569/josm

 L'idée est de petit à petit gagner en homogénéité sur la manière de
 tagguer un multipolygon. Jusque là, c'est souvent le(s) ways avec le rôle
 outer qui portaient les tags décrivant en fait tout le multipolygon. Le
 warning est une incitation à transférer ces tags directement au niveau de
 la relation : plus cohérent en modélisation, et du coup plus simple à
 interpréter par les logiciels clients comme osm2pgsql.

 vincent



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

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

Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien

2014-10-15 Thread Francescu GAROBY

Et faire 2 relations, une par leaf_type, c'est pas envisageable ?

Le 15 octobre 2014 16:11, Mides mides@gmail.com a écrit :

 Coté pratique, si je crée un multi polygone  avec 2 outer et un
 inner comportant  deux objet dont un avec un trou,  les tag de surfaces
 doivent, si j'ai bien compris, se retrouver dans le multi polygone.

 tags Multi polygone :

- landuse = forest
- leaf_type = broadleaved
- type = multipolygon

 Mais si par exemple les polygones ont un leaf_type différent :

- leaf_type = mixed
- leaf_type = broadleaved

 Je les place où ces tags ? Je suppose au niveau de chaque polygone et
 retirer celui qui à été généré en auto au niveau du multi, c'est cela !

 Michel



 Le 15 octobre 2014 15:37, Nicolas Moyroud nmoyr...@free.fr a écrit :

 Oui c'est sûr que dans l'esprit ce n'est pas une mauvaise chose dans
 l'idée, mais dans la réalisation c'est une catastrophe. Je veux dire ce
 genre de message cryptique pour un non-initié et en plus non traduit en
 français. Le contributeur moyen qui modifie un simple tag sur un outer de
 multipolygon va se retrouver avec ce baratin qui lui pète à la tronche, ne
 rien comprendre et se barrer en courant de ce repaire de geo-geek ! Bon
 j'exagère un peu hein comme d'habitude, mais n'empêche... ;-)

 Nicolas

 -
 Nicolas Moyroud
 Site web libre@vous : http://libreavous.teledetection.fr
 -
 « Celui qui croit qu’une croissance infinie peut continuer indéfiniment
 dans un monde fini est soit un fou, soit un économiste. » Kenneth Boulding.

 Le 14/10/2014 22:37, Vincent de Château-Thierry a écrit :



 Ça date d'il y a quelques jours :
 http://josm.openstreetmap.de/changeset/7569/josm

 L'idée est de petit à petit gagner en homogénéité sur la manière de
 tagguer un multipolygon. Jusque là, c'est souvent le(s) ways avec le rôle
 outer qui portaient les tags décrivant en fait tout le multipolygon. Le
 warning est une incitation à transférer ces tags directement au niveau de
 la relation : plus cohérent en modélisation, et du coup plus simple à
 interpréter par les logiciels clients comme osm2pgsql.

 vincent



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



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




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

Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien

Oui, mais dans ce cas là nul besoin de relation puisque elles ne vont
comporter chacune qu'un membre.

Michel

Le 15 octobre 2014 16:18, Francescu GAROBY windu...@gmail.com a écrit :

 Et faire 2 relations, une par leaf_type, c'est pas envisageable ?

 Le 15 octobre 2014 16:11, Mides mides@gmail.com a écrit :

 Coté pratique, si je crée un multi polygone  avec 2 outer et un
 inner comportant  deux objet dont un avec un trou,  les tag de surfaces
 doivent, si j'ai bien compris, se retrouver dans le multi polygone.

 tags Multi polygone :

- landuse = forest
- leaf_type = broadleaved
- type = multipolygon

 Mais si par exemple les polygones ont un leaf_type différent :

- leaf_type = mixed
- leaf_type = broadleaved

 Je les place où ces tags ? Je suppose au niveau de chaque polygone et
 retirer celui qui à été généré en auto au niveau du multi, c'est cela !

 Michel



 Le 15 octobre 2014 15:37, Nicolas Moyroud nmoyr...@free.fr a écrit :

 Oui c'est sûr que dans l'esprit ce n'est pas une mauvaise chose dans
 l'idée, mais dans la réalisation c'est une catastrophe. Je veux dire ce
 genre de message cryptique pour un non-initié et en plus non traduit en
 français. Le contributeur moyen qui modifie un simple tag sur un outer de
 multipolygon va se retrouver avec ce baratin qui lui pète à la tronche, ne
 rien comprendre et se barrer en courant de ce repaire de geo-geek ! Bon
 j'exagère un peu hein comme d'habitude, mais n'empêche... ;-)

 Nicolas

 -
 Nicolas Moyroud
 Site web libre@vous : http://libreavous.teledetection.fr
 -
 « Celui qui croit qu’une croissance infinie peut continuer indéfiniment
 dans un monde fini est soit un fou, soit un économiste. » Kenneth Boulding.

 Le 14/10/2014 22:37, Vincent de Château-Thierry a écrit :



 Ça date d'il y a quelques jours :
 http://josm.openstreetmap.de/changeset/7569/josm

 L'idée est de petit à petit gagner en homogénéité sur la manière de
 tagguer un multipolygon. Jusque là, c'est souvent le(s) ways avec le rôle
 outer qui portaient les tags décrivant en fait tout le multipolygon. Le
 warning est une incitation à transférer ces tags directement au niveau de
 la relation : plus cohérent en modélisation, et du coup plus simple à
 interpréter par les logiciels clients comme osm2pgsql.

 vincent



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



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




 --
 Cordialement,
 Francescu GAROBY

 ___
 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 7588] Un message d'erreur que je ne comprends pas bien

2014-10-15 Thread JB


Si, c'est ce qu'il aurait toujours fallu faire, non ?
Il me semble que pour Pieren, c'est la simplicité de certains MP qui 
disparait, notamment celui avec un outer, un inner, et le building=house 
sur le outer, rien sur le inner, rien sur la relation. C'est rapide et 
compréhensible facilement.
Ça l'est moins quand il y a trois outer, avec des tags pas forcément 
identiques, des inners, avec d'autres tags, et la relation, encore 
d'autres choses. Non, j'ai pas prononcé landuse ni Corine (ni iD ni 
Potlatch d'ailleurs)… juste pensé très fort.

JB.


Le 15/10/2014 16:18, Francescu GAROBY a écrit :

Et faire 2 relations, une par leaf_type, c'est pas envisageable ?

Le 15 octobre 2014 16:11, Mides mides@gmail.com 
mailto:mides@gmail.com a écrit :


Coté pratique, si je crée un multi polygone  avec 2 outer et un
inner comportant  deux objet dont un avec un trou,  les tag de
surfaces doivent, si j'ai bien compris, se retrouver dans le multi
polygone.

tags Multi polygone :

  * landuse = forest
  * leaf_type = broadleaved
  * type = multipolygon

Mais si par exemple les polygones ont un leaf_type différent :

  * leaf_type = mixed
  * leaf_type = broadleaved

Je les place où ces tags ? Je suppose au niveau de chaque polygone
et retirer celui qui à été généré en auto au niveau du multi,
c'est cela !

Michel



Le 15 octobre 2014 15:37, Nicolas Moyroud nmoyr...@free.fr
mailto:nmoyr...@free.fr a écrit :

Oui c'est sûr que dans l'esprit ce n'est pas une mauvaise
chose dans l'idée, mais dans la réalisation c'est une
catastrophe. Je veux dire ce genre de message cryptique pour
un non-initié et en plus non traduit en français. Le
contributeur moyen qui modifie un simple tag sur un outer de
multipolygon va se retrouver avec ce baratin qui lui pète à la
tronche, ne rien comprendre et se barrer en courant de ce
repaire de geo-geek ! Bon j'exagère un peu hein comme
d'habitude, mais n'empêche... ;-)

Nicolas

-
Nicolas Moyroud
Site web libre@vous : http://libreavous.teledetection.fr
-
« Celui qui croit qu’une croissance infinie peut continuer
indéfiniment dans un monde fini est soit un fou, soit un
économiste. » Kenneth Boulding.

Le 14/10/2014 22:37, Vincent de Château-Thierry a écrit :



Ça date d'il y a quelques jours :
http://josm.openstreetmap.de/changeset/7569/josm

L'idée est de petit à petit gagner en homogénéité sur la
manière de tagguer un multipolygon. Jusque là, c'est
souvent le(s) ways avec le rôle outer qui portaient les
tags décrivant en fait tout le multipolygon. Le warning
est une incitation à transférer ces tags directement au
niveau de la relation : plus cohérent en modélisation, et
du coup plus simple à interpréter par les logiciels
clients comme osm2pgsql.

vincent



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



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




--
Cordialement,
Francescu GAROBY


___
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 7588] Un message d'erreur que je ne comprends pas bien

2014-10-15 Thread Francescu GAROBY

Ça dépend où se situe le trou : s'il est à cheval entre les 2 zones ou s'il
est complètement inclus dans l'une d'entre elles.

Le 15 octobre 2014 16:22, Mides mides@gmail.com a écrit :

 Oui, mais dans ce cas là nul besoin de relation puisque elles ne vont
 comporter chacune qu'un membre.

 Michel

 Le 15 octobre 2014 16:18, Francescu GAROBY windu...@gmail.com a écrit :

 Et faire 2 relations, une par leaf_type, c'est pas envisageable ?

 Le 15 octobre 2014 16:11, Mides mides@gmail.com a écrit :

 Coté pratique, si je crée un multi polygone  avec 2 outer et un
 inner comportant  deux objet dont un avec un trou,  les tag de surfaces
 doivent, si j'ai bien compris, se retrouver dans le multi polygone.

 tags Multi polygone :

- landuse = forest
- leaf_type = broadleaved
- type = multipolygon

 Mais si par exemple les polygones ont un leaf_type différent :

- leaf_type = mixed
- leaf_type = broadleaved

 Je les place où ces tags ? Je suppose au niveau de chaque polygone et
 retirer celui qui à été généré en auto au niveau du multi, c'est cela !

 Michel



 Le 15 octobre 2014 15:37, Nicolas Moyroud nmoyr...@free.fr a écrit :

 Oui c'est sûr que dans l'esprit ce n'est pas une mauvaise chose dans
 l'idée, mais dans la réalisation c'est une catastrophe. Je veux dire ce
 genre de message cryptique pour un non-initié et en plus non traduit en
 français. Le contributeur moyen qui modifie un simple tag sur un outer de
 multipolygon va se retrouver avec ce baratin qui lui pète à la tronche, ne
 rien comprendre et se barrer en courant de ce repaire de geo-geek ! Bon
 j'exagère un peu hein comme d'habitude, mais n'empêche... ;-)

 Nicolas

 -
 Nicolas Moyroud
 Site web libre@vous : http://libreavous.teledetection.fr
 -
 « Celui qui croit qu’une croissance infinie peut continuer indéfiniment
 dans un monde fini est soit un fou, soit un économiste. » Kenneth Boulding.

 Le 14/10/2014 22:37, Vincent de Château-Thierry a écrit :



 Ça date d'il y a quelques jours :
 http://josm.openstreetmap.de/changeset/7569/josm

 L'idée est de petit à petit gagner en homogénéité sur la manière de
 tagguer un multipolygon. Jusque là, c'est souvent le(s) ways avec le rôle
 outer qui portaient les tags décrivant en fait tout le multipolygon. Le
 warning est une incitation à transférer ces tags directement au niveau de
 la relation : plus cohérent en modélisation, et du coup plus simple à
 interpréter par les logiciels clients comme osm2pgsql.

 vincent



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



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




 --
 Cordialement,
 Francescu GAROBY

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



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




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

Re: [OSM-talk-fr] découpage administratif niveau 10 à la Ferté-Macé (Mayenne)

2014-10-15 Thread Pieren

Je suis très sceptique sur ces découpages (outre le choix des tags).
Rien ne délimite précisément un lieux-dit. Son étendue est très vague,
souvent issue d'une tradition orale. Même le cadastre est incapable de
dire si une parcelle appartient à un lieu-dit ou à celui d'à côté
(sauf s'il y a des adresses peut-être). Je pense que là, on fait trop
dans le pifométrique et on veut donner une apparence de précision à
quelque chose qui ne l'est pas.

Pieren

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

Re: [OSM-talk-fr] [Josm 7588] Un message d'erreur que je ne comprends pas bien