[OSM-talk-nl] Tagging laadpalen auto in Nederland

[Hugo hölscher]

Dag allemaal,

Bij het taggen van laadpalen die "los" op straat staan(voor elektrische 
auto's) loop ik tegen de naamgeving aan. Ik gebruik nu als name: de code 
die op de paal staat: bv cch0012334. Dat is een unieke code en deel van 
de ESVE (Europese officiele tag). Die lijkt langzaam te verdwijnen.


Soms zie je ook een adres waar de paal bij in de buurt staat, maar dat 
lijkt me niet beter.


Is hier al eerder over gedacht, ik heb in deze mail list niets gevonden.

Groet Hugo

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

[OSM-talk-nl] Tagging laadpalen auto in Nederland

[Hugo hölscher]

Dag allemaal,

Bij het taggen van laadpalen die "los" op straat staan(voor elektrische 
auto's) loop ik tegen de naamgeving aan. Ik gebruik nu als name: de code 
die op de paal staat: bv cch0012334. Dat is een unieke code en deel van 
de ESVE (Europese officiele tag). Die lijkt langzaam te verdwijnen.


Soms zie je ook een adres waar de paal bij in de buurt staat, maar dat 
lijkt me niet beter.


Is hier al eerder over gedacht, ik heb in deze mail list niets gevonden.

Groet Hugo



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

Re: [Talk-es] Herramienta para mejorar los procesos de creación de consensos en la comunidad

[hugo]

sirve para una sola cosa pero que no es aplicable a los miles de 
debates que estamos teniendo: Qué "name=" usamos y en qué idiomas? 
Wikidata o Wikipedia? Wikipedia en qué idiomas? Cómo aplicamos 
lifecycle "under construction" en carreteras? Pub, bar o biergarten y 
la realidad en España? Son algunos pocos ejemplos de temas 
polémicos que se me ocurren de golpe pero hay muchos más... y que 
se quedan allí tirando cada uno por su lado haciendo lo que le sale 
de los catanes. Además, el ejemplo también demuestra lo que 
estoy criticando.


Santiago Crespo (en Loomio): /No me gusta la toma de decisiones por 
mayoría. Prefiero por consenso, a través de la lista o de las 
reuniones mensuales (que deberíamos retomar). Los acuerdos se pueden 
publicar en la wiki./
Si fuera más sencillo llegar a consensos que satisfagan a todo el 
mundo OSM sería muy distinto. Usar Loomio no nos obliga hacer las 
cosas de una sola manera, lo decidimos nosotros: Queremos unanimidad? 
Pues se debate hasta que haya aprobación 100%. Queremos que se 
apruebe por mayoría amplia? Entonces decidimos que hay que llegar al 
60%, al 70% o al 80%, lo que nos parezca. Lo importante es que por 
fin lleguemos a ALGO y que aquello se pueda plasmar en la Wiki para 
que quede constancia.


Saludos,

Marcos Martinez


Am 12.10.2020 21:27, schrieb Miguel Sevilla-Callejo:


Hola de nuevo,

Quizá la wiki no sea la mejor y más dinámica forma para tomar 
decisiones pero por el momento es la vía que tenemos en la 
comunidad para llevar a cabo estas cuestiones.


Véase este ejemplo que se está llevando a cabo en estos momentos:

<https://wiki.openstreetmap.org/wiki/Proposed_features/Takeaway_drink_shops#voting>

Yo no descarto que en un futuro podamos usar otras herramientas como 
loomio pero veo compleja la opción de mover a la comunidad a otra 
herramienta 'alternativa' cuando las que ya tenemos no las usamos 
como debemos.





Saludos

Miguel

On Sun, 11 Oct 2020, 19:49 Carlos Cámara Menoyo via Talk-es, 
mailto:talk-es@openstreetmap.org>> wrote:

Hola a todos,

La verdad es que yo mismo me había planteado varias veces plantear 
usar loomio para la toma de decisiones en OSM por razones como las 
que expone Marcos, siendo la principal de ellas el hecho de que en 
los años que llevo en OSM me cuesta ver propuestas que se lleven a 
cabo precisamente porque las herramientas que usamos hacen que la 
conversación se diluya antes de que se llegue a algún consenso.


Sin duda, loomio mejoraría este proceso. En su momento también 
barajé opciones específicas para la toma de decisiones como 
<https://decidim.org/es/> (pensada para que la ciudadanía pueda 
proponer iniciativas, desarrollarlas y votarlas para llevarlas a 
cabo).


En aquél momento dejé de buscar porque por motivos personales 
también disminuyó el tiempo que le puedo dedicar a OSM y porque 
ambas soluciones eran de pago (al menos entonces -desconozco si 
ahora hay planes para organizaciones sin ánimo de lucro-).


En resumen, que me parece una propuesta genial y estoy convencido 
de que de llevarse a cabo mejoraría notablemente el proceso de 
toma de decisiones, haciendo de OSM un mapa mejor, y una comunidad 
más unida y proactiva (y con menos burn-out).


Saludos,

Carlos Cámara-Menoyo
<https://carloscamara.es/en>
https://carloscamara.es <https://carloscamara.es/>


‐‐‐ Original Message ‐‐‐
 On Sunday, 11 de October 2020 a les 18:32, Miguel Sevilla-Callejo 
mailto:msevill...@gmail.com>> wrote:

Estimados Marcos y Hugo,

Muchas gracias por la iniciativa.

Siento mucho el retraso en  la contestación.

Creo que la herramienta es muy interesante y efectivamente podría 
sernos de gran ayuda en la toma de decisiones pero creo que la 
wiki de OSM puede tener esta misma función.


Quizá la wiki no sea tan ágil o esté orientada directamente 
para realizar consultas pero, de hecho se usa para llevar a cabo 
la propuestas de etiquetas y es allí donde deberíamos de dejar 
por escrito los consensos o los debates resueltos en esta lista.


Creo que no solo es importante traerse los debates profundos del 
grupo de Telegram (y Riot) aquí, si no que es crucial 
trasladarlos a la wiki.


Por mi parte, de todos modos, voy a echarle un ojo a la instancia 
de loomio que comentáis pues sin duda sería una buena 
herramienta una vez tengamos una asociación (con socios) 
reactivada y en marcha.


Saludos

Miguel




On Tue, 15 Sep 2020, 01:53 Alejandro S., <mailto:alejandro...@gmail.com>> wrote:

Buenos días,
Últimamente estoy bastante desconcertado de osm, pero creo que 
esto es importante ¿no habría que consensuar en la lista el uso 
de una nueva herramienta para la toma de decisiones?


Saludos,
Alejandroscf


On Fri, Sep 11, 2020, 18:56 hugo <mailto:aumpfb...@gmail.com>> wrote:
Agrego un hilo de recopilación de enlaces para darle más 
contenido


<https://loomio.yourcityracing.com/d/KQhk14IA/enlaces-osm>

El jue, 10 de sep de 

Re: [Talk-es] Herramienta para rellenar el campo wikipedia*

[hugo]

Como comenta Polyglot, la etiqueta wikidata hace que tanto wikipedia 
(como multitud de otras etiquetas) queden "obsoletas". No es 
incorrecto, pero es redundante.
Desde el punto de vista técnico, una aplicación debe apuntar al tag 
wikidata, desde el que obtener la información que desee representar, 
ya sea el artículo de la Wikipedia, o los habitantes de determinada 
población.
De hecho, a raíz de este tema, recuerdo que en Telegram se creó 
cierta polémica al respecto, de sensibilidad lingüística, por el 
correcto etiquetado.


Un saludo

El mar, 13 de oct de 2020 a las 21:18, Jo  
escribió:
La ventaja del tag Wikidata es que normalmente ya no es tan necesario 
agregar el tag Wikipedia. Si alguien quiere más información, siga a 
la página wikidata y ahí puede ver en cuales idiomas hay páginas 
de Wikipedia. Además hay más objetos Wikidata que páginas WP, WD 
puede ser más específico y de esa manera más adecuado desde OSM.


Polyglot

On Tue, Oct 13, 2020 at 5:48 PM Xavier Barnada > wrote:

Hola lista,

Hace unos días me di cuenta de que hay elementos en OSM que tienen 
el campo wikidata pero no el campo wikipedia*. Creo que esta 
información se podría rellenar de forma automatizada usando la API 
de wikidata.


La idea sería crear un pequeño script en python para que 
cualquiera pudiera de forma automatizada corregir estos datos en su 
zona.



El flujo sería el siguiente:
1- Mediante overpass obtener todos los elementos que tienen el tag 
wikidata i no tienen wikipedia 
2- Consultar el valor de wikidata mediante la API de OSM 

3- Aceder a la api de Wikidata y leer el campo del link a la 
wikipedia 

4- Editar los datos de OSM para añadir todos los posibles valores 
por ejemplo wikidata:ca,wikidata:es.


Mis dudas son las siguientes:
- ¿Esto se considera una importación? A mi parecer no lo es.
- ¿Se tiene que reportar a algún sitio esta herramienta de 
edición automatizada? He revisado 
 y 
solo indica que se debe registrar aqui 



Si hay alguna duda o sugerencia será bienvenida

Saludos
Xavier Barnada



 ___
 Talk-es mailing list
Talk-es@openstreetmap.org 



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

Re: [Talk-es] Herramienta para mejorar los procesos de creación de consensos en la comunidad

[hugo]

Agrego un hilo de recopilación de enlaces para darle más contenido



El jue, 10 de sep de 2020 a las 19:40, m...@marcos-martinez.net 
escribió:

Hola todos,



Tal y como ya he anunciado en Telegram quiero dirigirme a la comundad 
ES para insistir en la necesidad de organizarnos con mayor 
eficiencia, sobre todo ahora que se está planteando constituir 
oficialmente un chapter nuevo dentro de OSM.




Afortunadamente nuestra comunidad se caracteriza por ser viva y 
entusiasta lo cual a menudo resulta en debates acalorados sobre temas 
muy diversos. Estos debates son necesarios y sanos pero creo que 
desperdiciamos energía y tiempo si no somos capazes de traducirlos 
en consensos tangibles. En mi humilde opinión, las consecuencias que 
más nos impactan son:




1. Es dificil confirmar con cifras que se haya llagado a una 
decisión u otra y por tanto no se puede actualizar legítimamente la 
Wiki, la cual debe recoger todas las normas que hemos acordado.




2. El punto anterior implica que los principiantes siguen sin tener 
pautas claras a medida que vamos afinándolas. Y como tienen dudas 
todo entran en telegram, sacan el tema – y volvemos a empezar.




3. Hay temas que aparecen con cierta recurrencia y como no podemos 
construir sobre un debate ya existente todo el mundo tiene que montar 
su argumentación desde zero cada vez.




4. A falta de números transparentes solo se puede intuir en qué 
consiste un nueve consenso y a veces parece que los que más ruido 
crean se llevan el gato al agua.




5. Un debate en Telegram no vale ya que no es un canal oficial y por 
tanto no llega a todo la comunidad y además no queda constancia de 
un hilo de debate.




6. Debates en la lista de mail sí llegan a toda la comunidad pero es 
poco intuitivo a la hora de seguir la discusión sobre un punto 
específico. Además no permite votar y concretar una resolución.




Todos estos puntos ha hecho reflexionar a algunos de la comunidad y 
con la inestimable ayudade J. Montesque lo ha instalado en su 
servidor,hemos empezado a probar una herramienta que nos puede ayudar 
y que ya está siendo utilizada tanto en la comunidad OSM de UK como 
enl a misma OSMF: LOOMIO








En LOOMIOse pueden crear “Threads” sobre cualquier tema 
permitiendo responder y crear un hilo espécifico sobre un aspecto 
dentro del thread, añadir documentos/fotos/etc. para documentar una 
opinión, hacer encuestas para sondear un tema ysobre todo:hacer una 
votación final. Los threas son públicos pero hay que crear un 
usuario para participar en el debate.




Quiero invitar a todo el mundo acrear un usuarioy probar las 
opciones, responder ahilosque ya hemos creado y/ocrear nuevos.Se 
trata de que la máxima cantidad de gente participe, sobre todo los 
veteranos con más conocimientos y con más presencia en los debates 
de Telegram.


Animo a crear hilos sobre temas que hemos discutido recientemente de 
forma controversa, como por ejemplo lo de los „name:es“ – que 
por cierto es representativo de los puntos criticados: en qué hemos 
quedado al final? Se ha debatido pero ha quedado el mal cuerpo de 
quecada uno lo haga como quiera sin resolver el problema de fondo.


Gracias por leer este tostón

Marcos (Mar Mar)



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

Re: [Talk-pt] key capital= (Padronização das localidades)

[Hugo Valentim]

É o que eu apliquei. Sim.

Apliquei-o, na altura, a tudo, excepto algumas dezenas de localidades sede de 
freguesia no distrito, salvo erro, da Guarda. Isto pq quem adicionou aí as 
freguesias a partir da CAOP não identificou os respectivos admin_centres, sendo 
agora necessário fazê-lo pesquisando-os manualmente, coisa que fiz nesse 
distrito para uns tantos mas não para todos.

A adição de capital=* aos nodos tem a vantagem de permitir distinguir, por 
exemplo num dado município, entre as localidades com a mesma classificação de 
place=*, quais as mais significativas/”importantes” do ponto de vista 
administrativo, independentemente das relações. Útil por exemplo para a 
definição do tamanho das fontes na etiquetagem…

Talvez fosse útil adicionar essa recomendação à documentação.

Cump.s


De: António Madeira<mailto:antoniomade...@gmx.com>
Enviado: 2 de agosto de 2020 19:28
Para: OSM Portugal<mailto:talk-pt@openstreetmap.org>; Hugo 
Valentim<mailto:hvalen...@hotmail.com>
Assunto: Re: [Talk-pt] key capital= (Padronização das 
localidades)

Mas isso já não é o que se aplica?
Por exemplo, Leiria (capital de distrito) tem capital=6.
Batalha (capital de concelho) tem capital=7.

Às 08:53 de 02/08/2020, Hugo Valentim escreveu:

Aqui há tempos tentei contribuir para clarificar a “hierarquia” de importância 
das localidades introduzindo paralelamente, nos “places”, a key “capital”, em 
que:

“capital= for subdivisions of countries - see 
boundary<https://wiki.openstreetmap.org/wiki/Key:boundary>=administrative<https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative>”

Veja-se: https://wiki.openstreetmap.org/wiki/Key:capital

Penso que qualquer revisão beneficiaria de igualmente o contemplar.

Cump.s


De: talk-pt-requ...@openstreetmap.org<mailto:talk-pt-requ...@openstreetmap.org>
Enviado: 2 de agosto de 2020 12:00
Para: talk-pt@openstreetmap.org<mailto:talk-pt@openstreetmap.org>
Assunto: Talk-pt Digest, Vol 127, Issue 1

Today's Topics:

   1. Padronização das localidades em Portugal (Sílvio Matos)
   2. Re:  Padronização das localidades em Portugal
  (Alexandre Moleiro)


--

Message: 1
Date: Sat, 1 Aug 2020 22:01:18 +0100
From: Sílvio Matos <mailto:aenar...@gmail.com>
To: talk-pt@openstreetmap.org<mailto:talk-pt@openstreetmap.org>
Subject: [Talk-pt] Padronização das localidades em Portugal
Message-ID:

<mailto:cajdetf-ilm94+9njfzyvpet6cakmgkjctttsfdtwkbmqgug...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Boa noite. Gostaria de trazer uma discussão a este grupo de modo a tentar,
de alguma forma, chegar a um consenso sobre o melhor padrão a usar em
Portugal para a tag place=*.

Neste momento, segundo a wiki, o padrão a usar é este:
https://wiki.openstreetmap.org/wiki/File:Fluxograma_Localidades.png

Este padrão, no entanto, não está a ser usado de maneira uniforme nas
edições que os contribuidores têm feito.
Em geral, a dúvida mais comum é como aglomerar 5 conceitos diferentes
(capital de distrito/sede de município/cidade/vila/freguesia) em 3 tags
possíveis (city/town/village).
Neste momento e, segundo a wiki, a tag "city" está reservada a capitais de
distrito, a tag "town" a todas as sedes de município, cidades e vilas, e a
tag "village" a freguesias ou sedes de município que não sejam pelo menos
vila (não conheço nenhum caso).

Actualmente esta regra, se aplicada à risca, cria alguns casos caricatos. É
fácil encontrar casos no Grande Porto e Grande Lisboa em que uma cidade
tenha várias freguesias que são elas próprias cidades ou vilas. Num exemplo
prático, a cidade de Vila Nova de Gaia partilhará a tag town com mais de
uma mão cheia de freguesias do seu concelho, o que a nível de renderização
pode trazer problemas - em zooms mais baixos/distantes Vila Nova de Gaia,
apesar de cidade e sede de concelho, poderá desaparecer em favor de uma
freguesia sua que seja vila.

O que proponho é uma alteração à regra existente, de forma à divisão ser
esta:

Capital de Distrito? -> place = city
Cidade ou Capital Administrativa de Município? -> place = town
Vila ou Capital Administrativa de Freguesia (não urbana)? -> place = village
Capital Administrativa de Freguesia (urbana)? -> place = neighbourhood

Esta mudança efectivamente cria distinções entre cidades e vilas, ao mesmo
tempo que preserva uma hierarquia em termos de divisões administrativas,
sem criar casos caricatos como o acima descrito.

Numa nota final, questiono se fará sentido despromover todas as sedes de
freguesia para place=neighbourhood, por uma questão lógica. Não incluí essa
distinção no caso acima, incluindo apenas as freguesias urbanas nessa tag,
porque no contexto nacional a maioria das sedes de freguesia rurais têm
efectivamente a identidade e contexto histórico de um povoado distinto, ao
contrário da maioria (e aqui podemos argum

[Talk-pt] key capital= (Padronização das localidades)

[Hugo Valentim]

Aqui há tempos tentei contribuir para clarificar a “hierarquia” de importância 
das localidades introduzindo paralelamente, nos “places”, a key “capital”, em 
que:

“capital= for subdivisions of countries - see 
boundary=administrative”

Veja-se: https://wiki.openstreetmap.org/wiki/Key:capital

Penso que qualquer revisão beneficiaria de igualmente o contemplar.

Cump.s


De: talk-pt-requ...@openstreetmap.org
Enviado: 2 de agosto de 2020 12:00
Para: talk-pt@openstreetmap.org
Assunto: Talk-pt Digest, Vol 127, Issue 1

Today's Topics:

   1. Padronização das localidades em Portugal (Sílvio Matos)
   2. Re:  Padronização das localidades em Portugal
  (Alexandre Moleiro)


--

Message: 1
Date: Sat, 1 Aug 2020 22:01:18 +0100
From: Sílvio Matos 
To: talk-pt@openstreetmap.org
Subject: [Talk-pt] Padronização das localidades em Portugal
Message-ID:

Content-Type: text/plain; charset="utf-8"

Boa noite. Gostaria de trazer uma discussão a este grupo de modo a tentar,
de alguma forma, chegar a um consenso sobre o melhor padrão a usar em
Portugal para a tag place=*.

Neste momento, segundo a wiki, o padrão a usar é este:
https://wiki.openstreetmap.org/wiki/File:Fluxograma_Localidades.png

Este padrão, no entanto, não está a ser usado de maneira uniforme nas
edições que os contribuidores têm feito.
Em geral, a dúvida mais comum é como aglomerar 5 conceitos diferentes
(capital de distrito/sede de município/cidade/vila/freguesia) em 3 tags
possíveis (city/town/village).
Neste momento e, segundo a wiki, a tag "city" está reservada a capitais de
distrito, a tag "town" a todas as sedes de município, cidades e vilas, e a
tag "village" a freguesias ou sedes de município que não sejam pelo menos
vila (não conheço nenhum caso).

Actualmente esta regra, se aplicada à risca, cria alguns casos caricatos. É
fácil encontrar casos no Grande Porto e Grande Lisboa em que uma cidade
tenha várias freguesias que são elas próprias cidades ou vilas. Num exemplo
prático, a cidade de Vila Nova de Gaia partilhará a tag town com mais de
uma mão cheia de freguesias do seu concelho, o que a nível de renderização
pode trazer problemas - em zooms mais baixos/distantes Vila Nova de Gaia,
apesar de cidade e sede de concelho, poderá desaparecer em favor de uma
freguesia sua que seja vila.

O que proponho é uma alteração à regra existente, de forma à divisão ser
esta:

Capital de Distrito? -> place = city
Cidade ou Capital Administrativa de Município? -> place = town
Vila ou Capital Administrativa de Freguesia (não urbana)? -> place = village
Capital Administrativa de Freguesia (urbana)? -> place = neighbourhood

Esta mudança efectivamente cria distinções entre cidades e vilas, ao mesmo
tempo que preserva uma hierarquia em termos de divisões administrativas,
sem criar casos caricatos como o acima descrito.

Numa nota final, questiono se fará sentido despromover todas as sedes de
freguesia para place=neighbourhood, por uma questão lógica. Não incluí essa
distinção no caso acima, incluindo apenas as freguesias urbanas nessa tag,
porque no contexto nacional a maioria das sedes de freguesia rurais têm
efectivamente a identidade e contexto histórico de um povoado distinto, ao
contrário da maioria (e aqui podemos argumentar) das sedes de freguesia
urbanas, que são historicamente vistas como sendo parte integrante da
cidade a que pertencem.

Agradeço desde já a vossa participação nesta discussão, pois é necessário
chegar a alguma conclusão neste tema, que já foi debatido várias vezes.
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Sun, 2 Aug 2020 10:50:01 +0100
From: Alexandre Moleiro 
To: OSM Portugal 
Subject: Re: [Talk-pt]  Padronização das localidades em Portugal
Message-ID:

Content-Type: text/plain; charset="utf-8"

Eu concordo com a proposta, notando que apenas nas Freguesias urbanas fará
sentido usar o neghbourhood.

Também há que levantar as questões de fundo:
-Haverá falta de tags para estes conceitos? Podem ser criadas? De certeza
já há discussão noutros países.
-Não fará sentido uma hierarquia com níveis, não se poderia usar a tag
admin_level também para places ?

Saudações
Alexandre

On Sat, 1 Aug 2020 at 22:02, Sílvio Matos  wrote:

>
> Boa noite. Gostaria de trazer uma discussão a este grupo de modo a tentar,
> de alguma forma, chegar a um consenso sobre o melhor padrão a usar em
> Portugal para a tag place=*.
>
> Neste momento, segundo a wiki, o padrão a usar é este:
> https://wiki.openstreetmap.org/wiki/File:Fluxograma_Localidades.png
>
> Este padrão, no entanto, não está a ser usado 

Re: [Talk-es] Ciclo de vida de una calle

[hugo]

Yo he estado usando old_name:fecha-fecha 
 para los nombres que 
comercios que han ido cambiando.
Hacerlo con name, a secas, parece que todavía es una propuesta 
 
(claro que desde nov, 2017 q se tocó por última vez).
De todos modos, me inclino por el old_name al referenciar a un nombre 
del pasado.


Saludo

El dom, 31 de may de 2020 a las 11:23, Jorge Sanz Sanfructuoso 
 escribió:

Buenas.

La semana pasada precisamente metí unos pocos 
name:etymology:wikidata para probar a partir de algo que se comento 
en Telegram. Me parece buena idea.


Saludos.

El dom., 31 may. 2020 a las 10:51, Héctor Ochoa 
(mailto:cie.hoc...@gmail.com>>) escribió:

Buenas,
muy buena idea.
Yo personalmente para el nombre uso name:etymology:wikidata 
(). Ejemplo: 



Saludos

El dom., 31 may. 2020 a las 10:16, Carlos Guallart 
(mailto:cguall...@gmail.com>>) escribió:

Es una buena idea.

El dom., 31 may. 2020 a las 10:09, Lanxana . (>) escribió:

Buenos días,

hace tiempo que le estoy dando vueltas a completar la información 
toponímica de las calles. Esto incluiría su ciclo de vida 
(cuando se creó, qué nombres ha tenido a lo largo del tiempo y 
en qué fechas), historia de su nombre (enlace a biografía 
personaje si fuera el caso) o incluso historia de la propia calle, 
si dispone de artículo en la wikipedia o código wikidata.


Para poder etiquetar bien estos datos, he estado buscando en la 
wiki cómo etiquetar este ciclo de vida. Estaba escribiendo ya un 
correo pidiendo ayuda, pero he encontrado información que me 
parece interesante compartir con la comunidad.


start_date= fecha desde la que hay constancia de que existe esta 
calle, ya sea histórica (una vía romana) o moderna 
(urbanización nueva)


[1] name= nombre oficial actual

[2] old_name= nombre con el que se conoció en algún momento y 
aún pervive en la memoria colectiva


name:fecha= fecha a partir de la cual tiene ese nombre

name:fecha1-fecha2 = período durante el cual tuvo ese nombre, 
cuando la fecha es completa (año-mes-día, según ISO-8601), se 
separan las fechas con un doble guión (por ejemplo, 
1900-01-01--1920-12-31) Aunque parece que este etiquetado está en 
propuesta[3].


Para la biografía del personaje, hay la opción de usar:

name:wikipedia= enlace al artículo

Espero os sea de ayuda, y si alguien quiere opinar/debatir sobre 
cómo etiquetar mejor el período de validez de un nombre, 
bienvenido sea! La propuesta que hay me parece coherente, y el 
ejemplo con una calle alemana le da mucho juego.


Saludos!

[1] https://wiki.openstreetmap.org/wiki/Names 


[2] 
[3] 


 ___
 Talk-es mailing list
Talk-es@openstreetmap.org 




--
Carlos Guallart

 ___
 Talk-es mailing list
Talk-es@openstreetmap.org 


 ___
 Talk-es mailing list
Talk-es@openstreetmap.org 




--
Jorge Sanz Sanfructuoso - Sanchi
Blog 


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

Re: [Talk-es] Día & Go, ¿supermarket or convenience?

[hugo]

Transmití a los que llevan el repositorio cuál son las principales 
discrepancias que hay en la comunidad española al respecto, y la 
última respuesta que obtuve sea quizás un poco tajante:
Dia & Go es siempre un supermarket Dia & Go es siempre una convenience 
store Dia & Go puede ser ambas, pues agregamos al índice ambas.
Actualmente el sondeo vía Telegram se ha girado a favor de 
convenience, 55% vs 45%


En mi opinión la mayor conflictividad que trae esta etiqueta radica en 
la traducción que se hizo en su día de convenience como ultramarinos. 
En el mundo de la alimentación sí que se discriminan los distintos 
tipos de supermercados aunque en el día a día, el común de las 
personas, los sigamos llamando /supers/. A modo de comparatoria, en OSM 
se dintiguen highway=residential, living_street, pedestrian... sin 
embargo, en el día a día decimos /calle./

/
/
La principal diferencia está en torno a la banda horaria que puede 
abrir, y en menor medida tamaño del establecimiento o precios. Sin 
mencionar ya que la regulación será distinta para este tipo de 
comercios. En el caso concreto del /Dia & Go/, el hecho que en su 
propio blog  se denominen como tienda 
de conveniencia (como ya he dicho, en el mundillo esa es la 
denominación) hace más difícil incluso hacer que acepten la etiqueta 
supermercado.


Un saludo

El mar, 26 de may de 2020 a las 11:38, Alejandro Moreno 
 escribió:
Yo solo conozco un Dia así que mi opinión se basa solo en ese 
establecimiento. Para mí es un supermarket porque tiene sección de 
frescos, es decir, charcutería, carnicería y pescadería con su 
charcutero, carnicero y pescadero; además de tener un tamaño medio. 
Además es bastante similar a los Opencor y Supercor que conozco y 
que también se etiquetan como supermarket.


Yo, el tener charcutería, carnicería y pescadería es el argumento 
que daría para insistir en que es un supermarket.


El dom., 24 may. 2020 a las 16:37, Crashillo (>) escribió:
Supongo que gran parte de la comunidad OSM de españa ya estaréis 
al tanto de

 la /polémica/ pero hago un resumen rápido:

 - El objetivo es poder controlar los brands /Dia & Go/
 - Se ha propuesto una incorporación al registro oficial, se puede 
seguir en
 este enlace 

 - El sondeo de opinión en el telegram es 44% a favor de 
*convenience* VS.

 54% a favor de *supermarket*
 - Los que llevan el repositorio en Github se muestran reticentes a 
aceptar

 *supermarket*

 Pido opinión de la comunidad, ¿qué hacemos?
 - Se puede aceptar lo que sugieren
 - Se pueden insistir en *supermarket* (ruego ayuda en este tema)
 - Se puede desestimar la incorporación, no incluirlo en el 
registro.


 La no-actuación conlleva que desestimen ese elemento, por tanto no 
se

 incluya.

 Saludos



 --
 Sent from: 

 ___
 Talk-es mailing list
Talk-es@openstreetmap.org 



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

Re: [Talk-es] Demarcaciones sanitarias

[hugo]

Como bien dice David, es más fácil usar /admin_level/ sobre todo si 
el número a añadir es un nivel administrativo. Por eso, y por 
simplicidad con lo ya existente, en la wikipedia 
<https://wiki.openstreetmap.org/wiki/ES:Otros_L%C3%ADmites> ya están 
actualizadas.


Por otro lado, has añadido los límites religiosos, te quería 
preguntar si tienes alguna fuente de referencia para incluirlo en la 
página. Las referencias de Wikipedia están rotas ya, y lo único que 
he encontrado es 
<https://conferenciaepiscopal.es/iglesia-en-espana/mapa-eclesiastico/> 
pero no es descargable, y desconozco si podemos usarlo como fuente.


Respecto al etiquetado de la propuesta, he creado la discusión aquí 
<https://wiki.openstreetmap.org/wiki/ES_talk:Otros_L%C3%ADmites> para 
tenerlo al lado del propio artículo. Veréis que ya he comentado sobre 
la posible confusión healthcare=specialities con 
helthcare:specialities=*


Por último, cómo veis las fuentes son de Castilla y León en su 
mayoría. Si sois de otra comunidad, y disponéis/conocéis las 
fuentes, por favor, añadidlas para poder mapearlas.


Un saludo

El jue, 28 de may de 2020 a las 08:37, David Marín Carreño 
 escribió:
Mi pregunta es por qué se están proponiendo distintas etiquetas de 
nivel (healthcare_level, environment_level) en lugar de la ya 
existente admin_level.


Esta etiqueta ya está siendo usada por 
boundary=religious_administration tanto en Polonia como Alemania.


--
David Marín Carreño mailto:dav...@gmail.com>>



El mié., 27 may. 2020 a las 20:20, hugo (<mailto:aumpfb...@gmail.com>>) escribió:
Respecto a lo de proponerlo sin duda es el camino, pero antes 
queríamos tenerlo un poquito más organizado. Para ello he creado 
esta página: 
<https://wiki.openstreetmap.org/wiki/ES:Otros_L%C3%ADmites>.


Mi idea es que podamos editar en esta página (quién quiera) 
algunas ideas tanto de tags, como de fuentes (mayoritariamente son 
de CyL ahora) antes de elaborar una propuesta formal (como aquí se 
describe <https://wiki.openstreetmap.org/wiki/Proposal_process>). Si 
alguien no sabe editar en wikipedia o no tiene cuenta o lo que sea, 
puede mandar un correo aquí para que se agregue el contenido.


Saludos

El mar, 26 de may de 2020 a las 11:25, Alejandro Moreno 
mailto:almo...@gmail.com>> escribió:
Yo no puedo aportar mucho al etiquetado pero os dejo un par de 
propuestas. La primera es proponerlo en la lista de etiquetado 
global ya que ahí pueden proponer otras opciones de etiquetado y 
la segunda es documentar en la wiki la solución que finalmente se 
use, de manera que quede reflejado las etiquetas a usar como 
documentación para el futuro.


Un saludo.

El lun., 25 may. 2020 a las 12:04, Jorge Sanz Sanfructuoso 
(mailto:sanc...@gmail.com>>) escribió:

Buenas.

A lo mejor se puede hacer igual que en las zonas administrativas 
que se añade en la relación un admin_center. Añadir en estas 
zonas algo parecido con el centro de salud principal de la 
demarcación sanitaria.


Un saludos.


El lun., 25 may. 2020 a las 2:43, Diego Cruz (<mailto:ginkar...@gmail.com>>) escribió:

Hola, Rafael:

Muchas gracias por tu respuesta.

Un compañero me ha advertido de que el único país donde estaba 
mapeado esto era el Congo, y allí utilizaban "health". Sin 
embargo, yo diría que "health" en inglés es más bien la salud 
de uno mismo, mientras que "healthcare" se refiere a la sanidad o 
atención sanitaria. Por eso había optado por esto último 
(además de que está el grupo de etiquetas "healthcare").


Acabo de subir la primera zona básica de salud (rural) como 
ensayo piloto (changeset #85697721) y al hacerlo me he dado 
cuenta de algunos fallos en lo que había propuesto, como el tema 
de la referencia que mencionas. Coincido en que es una tontería 
inventarse "health_ref", así que había puesto ref:healthcare, 
pero si basta con "ref" a secas, por mí no hay problema, lo 
cambio. No soy muy experto en el tema de las referencias.


Es decir, me parece perfecto lo que dices (*boundary=healthcare + 
healthcare_level=X*) con ref a secas, pero cambiando health por 
healthcare (aunque se esté usando ya health, yo creo que si se 
propone a nivel mundial la gente de habla inglesa no va a aceptar 
health, aunque todo es cuestión de ver qué pasa).


En cuanto al etiquetado de los centros, teniendo en cuenta el 
conflicto existente entre amenity=x y healthcare=x que han 
mencionado algunos compañeros, he optado por poner las dos, y 
que se borre automáticamente después la que quede en desuso.


También he visto que para los consultorios de atención primaria 
sería "doctors" y no "doctor" como había puesto.


Un saludo
Diego


El lun., 25 may. 2020 a las 1:59, Rafael Avila Coya 
(mailto:ravilac...@gmail.com>>) escribió:

Hola, Diego:

En la República Dem. del Congo se están mapeando las zonas 
sanitarias del país. Hace unos años atrás

Re: [Talk-es] Demarcaciones sanitarias

[hugo]

Respecto a lo de proponerlo sin duda es el camino, pero antes 
queríamos tenerlo un poquito más organizado. Para ello he creado esta 
página: .


Mi idea es que podamos editar en esta página (quién quiera) algunas 
ideas tanto de tags, como de fuentes (mayoritariamente son de CyL 
ahora) antes de elaborar una propuesta formal (como aquí se describe 
). Si alguien no 
sabe editar en wikipedia o no tiene cuenta o lo que sea, puede mandar 
un correo aquí para que se agregue el contenido.


Saludos

El mar, 26 de may de 2020 a las 11:25, Alejandro Moreno 
 escribió:
Yo no puedo aportar mucho al etiquetado pero os dejo un par de 
propuestas. La primera es proponerlo en la lista de etiquetado global 
ya que ahí pueden proponer otras opciones de etiquetado y la segunda 
es documentar en la wiki la solución que finalmente se use, de 
manera que quede reflejado las etiquetas a usar como documentación 
para el futuro.


Un saludo.

El lun., 25 may. 2020 a las 12:04, Jorge Sanz Sanfructuoso 
(mailto:sanc...@gmail.com>>) escribió:

Buenas.

A lo mejor se puede hacer igual que en las zonas administrativas que 
se añade en la relación un admin_center. Añadir en estas zonas 
algo parecido con el centro de salud principal de la demarcación 
sanitaria.


Un saludos.


El lun., 25 may. 2020 a las 2:43, Diego Cruz (>) escribió:

Hola, Rafael:

Muchas gracias por tu respuesta.

Un compañero me ha advertido de que el único país donde estaba 
mapeado esto era el Congo, y allí utilizaban "health". Sin 
embargo, yo diría que "health" en inglés es más bien la salud de 
uno mismo, mientras que "healthcare" se refiere a la sanidad o 
atención sanitaria. Por eso había optado por esto último 
(además de que está el grupo de etiquetas "healthcare").


Acabo de subir la primera zona básica de salud (rural) como ensayo 
piloto (changeset #85697721) y al hacerlo me he dado cuenta de 
algunos fallos en lo que había propuesto, como el tema de la 
referencia que mencionas. Coincido en que es una tontería 
inventarse "health_ref", así que había puesto ref:healthcare, 
pero si basta con "ref" a secas, por mí no hay problema, lo 
cambio. No soy muy experto en el tema de las referencias.


Es decir, me parece perfecto lo que dices (*boundary=healthcare + 
healthcare_level=X*) con ref a secas, pero cambiando health por 
healthcare (aunque se esté usando ya health, yo creo que si se 
propone a nivel mundial la gente de habla inglesa no va a aceptar 
health, aunque todo es cuestión de ver qué pasa).


En cuanto al etiquetado de los centros, teniendo en cuenta el 
conflicto existente entre amenity=x y healthcare=x que han 
mencionado algunos compañeros, he optado por poner las dos, y que 
se borre automáticamente después la que quede en desuso.


También he visto que para los consultorios de atención primaria 
sería "doctors" y no "doctor" como había puesto.


Un saludo
Diego


El lun., 25 may. 2020 a las 1:59, Rafael Avila Coya 
(mailto:ravilac...@gmail.com>>) escribió:

Hola, Diego:

En la República Dem. del Congo se están mapeando las zonas 
sanitarias del país. Hace unos años atrás colaboré con Claire 
Halleux de la comunidad local congolesa sobre el tagging para esas 
entidades, pues no teníamos referencia en otros países.


Por consistencia con los datos que ya hay, estaría bien seguir 
ese esquema, y quizás luego proponerlo para la wiki global para 
que en otros países se siga también este mismo esquema, y no que 
haya varios esquemas diferentes para lo mismo.


La sección en la que se explica es esta: 



Basicamente es boundary=health + health_level=X

En cuanto a ref, podría usarse la etiqueta ref=* que ya existe en 
la wiki, en vez de crear una health_ref.


Saludos,

Rafael.

O 24/05/20 ás 21:54, Diego Cruz escribiu:

Hola a todos:

En el grupo de Castilla y León hemos estado hablando sobre 
mapear una serie de límites territoriales y por iniciativa 
personal he propuesto empezar con los distritos sanitarios. Os 
dejo un esquema de mi propuesta para los usuarios de Castilla y 
León y por si pudiese aprovecharse en otras autonomías.


El territorio podría dividirse utilizando la etiqueta 
*boundary=healthcare_administration*, siguiendo el ejemplo de 
religious_administration (y que podría copiarse para 
environment_administration o agriculture_administration en otras 
demarcaciones que existen a nivel local). Para los tres niveles 
de organización que hay (autonomía, áreas de salud y zonas 
básicas de salud) podría utilizarse *healthcare_level* al modo 
de admin_level. Es decir:


Área de salud de León
/name=León
/
/boundary=healthcare_administration/
/healthcare_level=6/ (nivel de provincia)

Zona básica de salud de Babia
/name=Babia/
/boundary=healthcare_administration/
/healthcare_level=7/ (nivel de 

Re: [Talk-pt] Estuário do Tejo & linha de costa (Topo Lusitania)

[Hugo Valentim]

OK. Compreendi o histórico.

A coastline, de facto, é renderizada a partir de informação tratada em separado 
(os shapefiles publicamente disponíveis são supostamente actualizados a cada 12 
horas, não tenho a certeza se o openstreemap.org se actualiza com a mesma 
frequência…).

Ora, do meu ponto de vista, no instante actual, a vantagem em usar a coastline 
para demarcar o Estuário reside precisamente no facto de ela não ser, do ponto 
de vista da edição do mapa, um polígono. O único requisito para não a “quebrar” 
é manter uma linha contínua de segmentos, um procedimento automático existe < 
https://osmcode.org/osmcoastline/> que se encarrega de gerar os polígonos de 
“água” com o devido limite de 2000 pontos (em obediência à API v6) – por 
coincidência ou não gerando o mesmíssimo resultado do plugin Split do QGIS. 
Provavelmente os ficheiros  também poderão 
ser usados na geração de mapas para Garmin.

O uso da coastline também admite a renderização do natural=shoal (áreas a 
descoberto na maré baixa, o que não sucede se a margem for definida como 
riverbank), embora em última análise isso seja uma especificidade do 
mapnik-carto.

Por outro lado, há ainda, por inerência, a questão da exclusão/inclusão (imagem 
inversa) nos polígonos da terra. A linha de água do Estuário do Tejo 
actualmente acaba em frente ao Cais do Sodré (Gargalo do Tejo).

Assim, no instante presente, talvez não fosse má ideia incorporar o Mar da 
Palha simultaneamente na coastline e no multipolígono Iberian Peninsula?

Cump.s,
H. Valentim


De: talk-pt-requ...@openstreetmap.org
Enviado: 11 de junho de 2019 13:00
Para: talk-pt@openstreetmap.org
Assunto: Talk-pt Digest, Vol 113, Issue 4

Today's Topics:

   1. Re: Estuário do Tejo & linha de costa (Topo Lusitania Lusitania)
   2. Re: Estuário do Tejo & linha de costa (Topo Lusitania Lusitania)

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

[Talk-pt] Estuário do Tejo & linha de costa

[Hugo Valentim]

Boa tarde,

A subtracção do Estuário do Tejo (mormente o multipolígono “Mar da Palha”), 
salobro e sujeito ao efeito da maré, à  linha de costa - por exemplo ao 
contrário do Estuário do Sado - não parece uma opção especialmente consistente, 
também porque está fora do perfil da própria Península (multipolígono “Iberian 
Peninsula”).

Não seria melhor incorporá-lo dentro da coastline, ou há alguma razão que eu 
desconheça para estar como está?

Cump.s,
H. Valentim

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

Re: [OSM-talk-nl] Problemen met downloaden kaarten

[Hugo hölscher]

Dag Leentje,

alternatief  als je een Android tablet of telefoon hebt is: OSMAND.  
Gratis versie heeft beperking voor het aantal kaarten wat je tegelijk 
kunt hebben (Nieuw-Zeeland is er 1) en er zijn diverse betaalde 
uitbreidingen. Het is een off-line  app. Voordeel van een tab is dat het 
lekker groot is,)


succes Hugo


Op 9-2-2019 om 09:28 schreef Leentje Osselaer:

Dankje Marc,
De site lijkt toch betalend, of kijk ik over uw optie van de gratis 
versie? Als ik  zeker de juiste formats kan downloaden, wil ik er wel 
voor betalen.

Groeten,
Leentje
*From:* Marc Zoutendijk via Talk-nl <mailto:talk-nl@openstreetmap.org>
*Sent:* Wednesday, February 6, 2019 7:27 PM
*To:* OpenStreetMap NL discussion list <mailto:talk-nl@openstreetmap.org>
*Cc:* Marc Zoutendijk <mailto:marczoutend...@mac.com>
*Subject:* Re: [OSM-talk-nl] Problemen met downloaden kaarten

Op 6 feb. 2019, om 16:18 heeft Leentje Osselaer 
mailto:leentje.ossel...@skynet.be>> het 
volgende geschreven:

Hallo,
Ik weet niet of ik hier aan het juiste adres ben, maar ik zou een 
kaart van Nieuw-Zeeland willen downloaden, waar we volgende week 
naartoe gaan. Ik krijg echter steeds het volgende bericht. 

Is er inderdaad iets fout met de server? Kunnen jullie helpen?



Vergeet die server zoals ook al uit een andere reactie blijkt.
Probeer deze oplossing:
https://www.velomap.org/
In de gratis versie kun je 3 downloads per maand doen. Ik gebruik zelf 
Velomap (met abonnement) voor alle landen die niet door OFM 
(OpenFietsMap) worden gedekt.

En anders kun je met deze:
https://extract.bbbike.org/
ook je doel bereiken.
En in het vervolg kun je je beter tot het forum wenden dan tot deze 
mailinglijst, want die wordt door ongeveer 5 mensen gelezen en het 
forum is wat drukker bezocht.

Groet
Marc.


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

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

[Talk-pt] E Olivença (também) é nossa!

[Hugo Valentim]

Numa nota meio patrioteira, meio estritamente prática: terei sido o único a 
notar que os sr.s do Geofabrik* usando um polígono inadequado de Portugal, que 
deixa de fora as Ilhas Selvagens**?


Bora lá todos enviar um  e-mail a pedir rectificação, que eles pelos vistos só 
achariam mesmo digno de atenção se fosse o Schleswig-Holstein a surgir como 
parte da Dinamarca, ou coisa que o valha: i...@geofabrik.de

* http://download.geofabrik.de/europe/portugal.html

** https://pt.wikipedia.org/wiki/Ilhas_Selvagens

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

[Talk-pt] Disponível c/ actualização diária: dados OSM em formatos Mapsforge (para Oruxmaps etc.)

[Hugo Valentim]

Aqui: http://valentim.org/portugal-latest-osm-mapsforge


"Portugal country data from OpenStreetMap in Mapsforge formats. Suitable for 
OruxMaps, Locus, Cruiser and the like.

Contrary to monthly updates available elsewhere, this one is updated every day, 
from Geofabrik, at ~03:00 (Lisbon Time)."


Cump.s,

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

Re: [OSM-talk-nl] blog.openstreetmap.nl

[Hugo Hölscher]

Is de blog soms slachtoffer van het recent ontdekte lek in PHPMailer?

Er is overigens een patch on het lek te dichten.

Groet Hugo


Op 18 feb. 2017 12:24 schreef "Stefan de Konink" <ste...@konink.de>:

> Ps maar als er een vrijwilliger komt die het in de lucht wil gaan houden,
>> ga uwes ganges en draag het over.
>>
>
> Ik heb nog wat liefde gegeven aan de wordpress installatie. Hij is nog
> niet weg.
>
> --
> Stefan
>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl
>
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

[OSM-talk-nl] Update nieuwbouw in Aerdenhout

[Hugo Holscher]

In Aerdenhout bij de Gezina van de Molenlaan en Mies Noltenlaan 
(http://www.openstreetmap.org/?mlat=52.36121=4.60237#map=19/52.36121/4.60237)
 zijn nieuwe woningen gebouwd. Ze zijn deels al sinds begin dit jaar bewoond. 
Ze staan echter nog niet op de kaart. Ik kan me niet voorstellen dat er geen 
kadaster gegevens zijn (na 2 jaar). Kan iemand nagaan of er iets mis is met de 
up-loads van de kadaster gegevens?

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

Re: [Talk-pt] Corte abrupto de dados na zona de Caminha, Portugal

[Hugo Barrocas]

Boas,

Seria uma questao de ver se houve dados apagados nessa area, mas a partida
acho que foi apenas alguem que preencheu aquele rectangulo com o maximo de
informaçao que conseguiu, principalmente nas tags 'landuse'.
Se repararem nas areas em redor, sao escassas as zonas completas com essas
informaçoes.


-- 
Cumprimentos,
D.er Hugo Barrocas
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-pt] Corte abrupto de dados na zona de Caminha, Portugal

[Hugo Barrocas]

Boas, isso fica perto da minha area de residencia, tambem ja tinha reparado
nesse estranho rectangulo e tentei contactar quem me pareceu ser o autor,
mas na altura acho que nao obtive resposta.

Ja andei a completar alguns bocados dessa area, para nao ter o formato
'rectangulo', mas tenho usado o meu tempo livre para corrigir as mais de
1000 anotaçoes que tenho espalhadas pelo norte do país, aos poucos de cada
vez, dando mais prioridade as vias rodoviarias.

Como essa area tem as vias correctas, ficou para segundo plano corrigir as
areas de 'landuse' cortadas.

Quando possivel posso completar mais essa zona.


-- 
Cumprimentos,
D.er Hugo Barrocas
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-pt] Conduta errática de um utilizador

[Hugo Barrocas]

Boas,

sobre as saidas de auto-estrada, eu antes tambem colocava o nó
motorway_junction  no meio da via de saida, depois passei a por no
inicio para ter um aviso mais atempado, e agora por fim, mudei de
ideias e passei a usar o sistema de turn:lanes para indicar as vias de
saida, e no final destas, colocar a saida com o motorway_link e o
motorway_junction.

exemplo:
http://www.openstreetmap.org/node/264335349

Isto resulta muito bem, principalmente para os programas de GPS que
usam os mapas OSM (eu uso o Osmand), pois primeiro dá indicação para
se manter a direita na altura em que começa a surgir a via de saida, e
+- ao meio, ao aproximar do final ainda reforça e volta a avisar para
virar à direita (se tudo estiver correcto nas tags).

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

Re: [Talk-pt] Workshop de georreferenciação na Águeda

[Hugo Teixeira]

Boas Marcos,

No âmbito do Agueda Living Lab tem-se feito alguns eventos das diversas
materias/atividades que tenham a ver com opensource desde o hardware até os
mapas :) Nasceram ali mais algumas ideias de futuros workshop's a realizar
;) Voltando a questão correu mt bem as pessoas ficaram com a noção do que
temos andado a fazer e como se pode contribuir.

Deixo aqui o desafio para se inscreverem na newsletter do ALL para
receberem as atividades de vamos proporcionando.

Abraço a todos,

Paulo - paulorosa...@gmail.com escreveu no dia Tue Feb 03 2015 at
13:00:08:

 Já é um começo. É pena estarem a publicitar o OSM e terem um mapa da
 Google para localizar o evento.
 Abraços.

 Paulo

 No dia 2 de fevereiro de 2015 às 10:50, Marcos Oliveira 
 marcosoliveira.2...@gmail.com escreveu:

 Olá a todos,

 Ontem ocorreu um workshop de onde o OpenStreetMap foi utilizado. [1]

 Alguém participou no evento? Se sim o que acharam?

 [1] - http://all.cm-agueda.pt/home/noticias/?SubsiteID=1news=37

 --
 Um Abraço,
 Marcos Oliveira

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

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

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

Re: [OSM-talk-nl] Almere wordt gesloopt

[Hugo Holscher]

Weten we zeker dat dit geen bot is? lijkt me wel heel veel werk voor een 
mens. Hier staat wie je kunt benaderen als het niet bij weinig blijft:

Data Working Group

Main article: Data working group The Data Working Group is authorised by the 
Foundation to deal with more serious vandalism and reports to the board at 
the monthly board meetings. In the rare case that the community approach 
doesn't work the issue should be reported to the data working group 
(d...@osmfoundation.org).


-Oorspronkelijk bericht- 
From: Jonathan van Tuijl

Sent: Friday, November 14, 2014 5:08 PM
To: OpenStreetMap NL discussion list
Subject: Re: [OSM-talk-nl] Almere wordt gesloopt

Familie Nouws schreef:

7.969 changesets in 11 maanden .


Inmiddels 8006. Nog geen reactie op mijn bericht van gisteren. Tags blijven 
ook al niet heel. Zo mogen we nu op wegen waar minstens een bromfiets nodig 
is lopen en fietsen. Hoe stop je dit? Hoe herstel je de schade op deze 
schaal effectief?


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



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

Re: [OSM-talk-nl] App toont voedselveiligheid Nederlandse lunchrooms

[Hugo Hölscher]

Er zijn meer van dat soort overheidsapp's die Google gebruiken.
Bijvoorbeeld OmgevingsAlert, waar de gemeente de  omgevings vergunningen
moet melden. Daar is OSM superieur aan Google omdat in OSM wel huisnummers
staan.  Dan weet je waar het echt is. Groet,  Hugo
Op 7 jul. 2014 14:52 schreef OpenStreetMap-Talk-nl 
openstreetmap-talk...@basdelange.com:

 Jammer dat Google Maps wordt gebruikt:
 http://www.nu.nl/tech/3821287/app-toont-voedselveiligheid-
 nederlandse-lunchrooms.html
 http://www.inspectieresultaten.vwa.nl/iframe/inspectieresultaten.html

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

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

Re: [Talk-it-southtyrol] Finally the import of the Housenumbers is complete!

[Hugo Leiter]

Congratulations!

I've checked a few house numbers and found one discrepancy: Jenesien 
Widumacker 18 is on Jenesien Birnbaum instead.


We could pass some of the checking work on to the municipalities .  For 
that, we would need a briefing on how this can be done efficiently.  
I'll see what we can do to improve the accuracy on our end especially 
when street names are changed (as planed in Kaltern and Ritten)  and 
when new homes are built.


Best Regards
Hugo Leiter

Am 31.03.2014 17:14, schrieb Pietro d'Orio:

Hi!
I am proud to say, that the import of the 118.723 house numbers of 
Province Bolzano that was missing in OpenStreetMap is complete!!!
You can see all the changesets of the import here 
https://www.openstreetmap.org/user/OpenGISData/history [1], or by 
visiting the wikipage 
https://wiki.openstreetmap.org/wiki/AltoAdige_-_S%C3%BCdtirol/OpenGisData_HouseNumber_Import2 
[2]


But the import is not still complete! We need the help of the community!
You need to check the data with a correspondence between the Province 
of Bolzano DB and the existing OSM housenumbers.
By test, i have made the update and the check of the house numbers 
that already exists in OpenStreetMap for my municipality (Merano)


Please follow this rules 
https://wiki.openstreetmap.org/wiki/AltoAdige_-_S%C3%BCdtirol/OpenGisData_HouseNumber_Import2#Import_of_the_housenumbers_that_exist_in_OSM 
[3] to make the updates!


You need to do anything for the following municipalities, 'cause are 
already completed:


  * La Val - Wengen - La Valle
  * Meran - Merano
  * Percha - Perca
  * Plaus
  * Prettau - Predoi
  * Proveis - Proves
  * Riffian - Rifiano
  * Salorno - Salurn (thanks to Naud)
  * Santa Cristina Gherdëina - S.Cristina Valgardena - St.Christina in
Gröden
  * Taufers im Münstertal - Tubre
  * Truden - Trodena
  * Vöran - Verano
  * Waidbruck - Ponte Gardena

Regards,

Pietro d'Orio

[1] https://www.openstreetmap.org/user/OpenGISData/history
[2] 
https://wiki.openstreetmap.org/wiki/AltoAdige_-_S%C3%BCdtirol/OpenGisData_HouseNumber_Import2
[3] 
https://wiki.openstreetmap.org/wiki/AltoAdige_-_S%C3%BCdtirol/OpenGisData_HouseNumber_Import2#How_to_update_the_data_in_JOSM









--
Ing. Hugo Leiter

EDV Abteilungsleiter
Südtiroler Gemeindenverband
Kanonikus-Michael-Gamper Straße 10
I-39100 Bozen
Tel. +39 0471 30 46 15   Fax +39 0471 30 46 60
hugo.lei...@gvcc.net - www.gvcc.net


Resp. reparto EDP
Consorzio dei Comuni della Provincia di Bolzano
Via Canonico Michael Gamper 10
I-39100 Bolzano
Tel. +39 0471 30 46 15  Fax +39 0471 30 46 60
hugo.lei...@gvcc.net - www.gvcc.net

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

Re: [Talk-it-southtyrol] [Mappers] Announce import of housenumbers in South Tyrol

[Hugo Leiter]

Great news!
Hugo Leiter

Am 07.02.2014 09:03, schrieb Pietro d'Orio:

Hi!!
The import of all the house numbers that are missing in the land South 
Tyrol are ready.


We have a long discussion with the local OSM community that have 
approved the import.


Here is a wiki page that describe the import: 
https://wiki.openstreetmap.org/wiki/AltoAdige_-_S%C3%BCdtirol/OpenGisData_HouseNumber_Import2


We want to do the import within 20.02.2014

Pietro d'Orio




___
Mappers mailing list
mapp...@opengisdata.eu
http://lists.opengisdata.eu/listinfo/mappers


--
Ing. Hugo Leiter

EDV Abteilung
Südtiroler Gemeindenverband
Kanonikus-Michael-Gamper Straße 10
I-39100 Bozen
Tel. +39 0471 30 46 15   Fax +39 0471 30 46 60
hugo.lei...@gvcc.net - www.gvcc.net


Reparto EDP
Consorzio dei Comuni della Provincia di Bolzano
Via Canonico Michael Gamper 10
I-39100 Bolzano
Tel. +39 0471 30 46 15  Fax +39 0471 30 46 60
hugo.lei...@gvcc.net - www.gvcc.net

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

Re: [OSM-talk-nl] BAG gegevens Re: OSM Navigatieapparatuur

[Hugo Hölscher]

Maarten et.al.

Mee eens. Was in januari een topic op de nieuwjaarsborrel. Daarna stil. Hugo
Op 29 mei 2013 09:23 schreef Maarten Deen md...@xs4all.nl het volgende:

 On 2013-05-29 09:11, Minko wrote:

  Wb adresnavigatie, zowel Lambertus' osm kaarten als mijn Openfietsmap
 zijn voorzien van alle BAG adressen.


 Ik was de BAG alweer helemaal vergeten, maar het lijkt me leuk om daar wat
 meer van te gaan importeren.
 De wikipagina's 
 http://wiki.openstreetmap.org/**wiki/BAGhttp://wiki.openstreetmap.org/wiki/BAGen
 http://wiki.openstreetmap.org/**wiki/BAGimporthttp://wiki.openstreetmap.org/wiki/BAGimportzijn
  niet erg uitgebreid, bij wie moet ik aankloppen?

  Hierdoor is NL landelijk dekkend, al zijn er nog veel gevallen waar


 De gegevens moeten wel in OSM zitten willen andere kaartgebruikers er
 voordeel van hebben.

 Maarten

 __**_
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-nlhttp://lists.openstreetmap.org/listinfo/talk-nl

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

Re: [OSM-talk] [Osmf-talk] Use of terms similar to GEOCODE

[Hugo Holscher]

Hi Simon,

that you may nor hear from them might be very true: see here: 
http://www.geocode.com/
Is apparently part of TomTom, so if you need more info, might be handy to check 
with them. They are Dutch so if I can oblige, let me know, Hugo


From: Simon Poole 
Sent: Thursday, May 23, 2013 2:38 PM
To: openstreetmap ; osmf-t...@openstreetmap.org 
Subject: [Osmf-talk] Use of terms similar to GEOCODE

 
As I promised in February I investigated with our North American counsel what 
they would consider acceptable use of terms similar to the GEOCODE trademark, 
they came back with  examples that they all considered OK. I've created a wiki 
page for future reference http://wiki.openstreetmap.org/wiki/Geocode_Trademark


I apologize for the delay, I was waiting for some closure on the matter, 
however the company in question has not responded to our correspondence. 
Personally I don't expect to hear from them again since it now must be clear 
that there is no money in it for them.


Simon










___
osmf-talk mailing list
osmf-t...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmf-talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-nl] Nieuwe Waalbrug A50

[Hugo Holscher]

Goedemiddag,

de OSM routeplanner bouwers zijn niet de eersten die hier tegenaan lopen. 
TomTom gebruikt de historische data over een weg om de “gemiddelde” snelheid te 
bepalen en daarmee de geschatte reistijd (en dat is behoorlijk nauwkeurig). Die 
dynamische gegevens zullen voorlopig wel buiten bereik van OSM zijn, maar wat 
je zou kunnen proberen is het effect van stoplichten op de route mee te nemen. 
Bijvoorbeeld: 1 stoplicht betekend gemiddeld 30 seconden vertraging. Met een 
door mappers ingevulde aanvullende tag: longest_waiting_time=75 seconde zou je 
een verfijning daarvan kunnen maken.
Dit zou ook voor fietsrouteplanners handig zijn: neem ik de route met 
stoplichten of ga ik meanderen en probeer ze te vermijden.
Hugo


From: Martien Scheepens 
Sent: Wednesday, May 22, 2013 1:42 PM
To: OpenStreetMap NL discussion list 
Subject: Re: [OSM-talk-nl] Nieuwe Waalbrug A50




2013/5/22 Maarten Deen md...@xs4all.nl

  On 2013-05-22 12:21, Martien Scheepens wrote:

Hoho. Dit is dus echt geen dataprobleem. Je algoritme kan zonder meer



  Daar ben ik het ook volledig mee eens. Taggen voor de router is het 
probleem van het algoritme verplaatsen naar de data. En dat moet je niet doen. 



een malus bevatten voor iedere actie die je als weggebruiker moet
doen. Dit maakt de resultaten ook robuster voor noise als kleine
zijstraatjes die 5 meter korter zijn. Daarnaast bevat OSM al data als
junction=roundabout, highway=traffic_signals
highway=motorway_junction, dus dit kun je zonder meer gebruiken als je
het nodig zou hebben. Dit probleem zou ook over de snelheden te sturen
moeten zijn.
Het is ook ronduit naïef om de maximumsnelheid te gebruiken. Voor
een afslag (waar je misschien 130 mag) is iets als 50 veel logischer.



  Vertel dat in Duitsland waar wegen buiten de bebouwde kom standaard 100 km/h 
zijn. Dat je dat op B-wegen vrijwel nooit kunt rijden weet de router niet.


Je zou in de router snelheden per wegtype op kunnen geven die je haalbaar 
lijken. Alternatief is dat je een percentage per wegtype verzint en deze 
toepast op de maximumsnelheid die in OSM staat. Hiermee voorkom je het probleem 
V_max  V_planner. 

Wat voor een Duitse B-weg gepast is, is wel een hele moeilijke. In het vlakke 
Niedersachsen op een overzichtelijke, goede klinkerweg is toch anders dan een 
bochtige, heuvelachtige asfaltweg in Bayern. In Duitsland werd mij door de 
instructeur geleerd om mijn eigen zintuigen te gebruiken, in Nederland wordt er 
een bord geplaatst...

Groeten,

Martien
 


  Maarten


2013/5/22 Maarten Deen md...@xs4all.nl


  On 2013-05-22 11:45, Floris Looijesteijn wrote:


in dat laatste geval zouden de 4 keer vaker afslaan toch echt
zwaarder moeten tellen dan die paar seconden tijdswinst.


  Het probleem is: wat is 4 keer vaker afslaan? Volgens de data is een 
rotonde oprijden ook een 90 graden bocht. Dus dan heb je ook al 4x afslaan via 
de normale route.


maar goed: genoeg ideeën maar geen kennis of tijd om het zelf beter te 
doen :)


  Hier ook. En dan ook nog een ontwikkelaar die IMHO wel erg snel dat is 
een dataprobleem zegt zodat hij de routingengine tenminste niet hoeft aan te 
passen.
  Moeten we straks niet alleen gaan taggen voor de renderer, maar ook nog 
taggen voor de router.

  Maarten

  20


  On 2013-05-22 09:27, Floris Looijesteijn wrote:


nee, dat kan er niet mee te maken hebben, dit is een route die van
tevoren berekend is.

misschien dat ie ter plekke inderdaad voor een 'parallelbaan' zou
kunnen kiezen als die niet helemaal lekker ligt.


  Het ligt er puur en alleen aan dat OSRM heel droog naar de snelste 
route kijkt. Paar voorbeelden:

  http://osrm.at/3eC [4] [4]
  http://osrm.at/3f6 [5] [5]
  http://osrm.at/2We [3] [3]
  http://osrm.at/3jr [6] [6] 


  Vooral die laatste vind ik wel leuk. De N556/Stationsstraat is 50 
km/h en de weg waarover gerouteerd wordt is vooral 80 km/h. In de berekening 
(wat heel simpel afstand/snelheid is) is die een paar seconden sneller. Maar 
goed, ik denk het voor iedereen wel duidelijk is dat je op die weg niet overal 
80 kunt rijden.
  OSRM is vrij dom wat dat betreft.

  Maarten


2013/5/21 St Niklaas st.nikl...@live.nl


  Kan de aanleg van nieuwe en bredere wegen, dus gps verschuivingen 
er debet aan zijn ? Het verschijnsel trad op bij Driebergen A12li en Vinkeveen 
A2re. In beide gevallen is het niet sneller om de afrit te nemen.
  hendrikklaas
   

  -
  From: hugoholsc...@gmail.com
  To: talk-nl@openstreetmap.org
  Date: Tue, 21 May 2013 17:05:50 +0200
  Subject: Re: [OSM-talk-nl] Nieuwe Waalbrug A50

  Ik heb een aantal van die vreemde routes bekeken en het komt 
omdat de routeplanner

Re: [OSM-talk-nl] Nieuwe Waalbrug A50

[Hugo Holscher]

Ik heb een aantal van die vreemde routes bekeken en het komt omdat de 
routeplanner de kortste of snelste route (maakt vaak niets uit) heel letterlijk 
 neemt. Je zult zien dat de afslag vaak een binnenbocht is en met de zelfde 
maximale snelheid dus korter en sneller is. Er is dus meer intelligentie in de 
route planner nodig om dat soort hele strikte beslissing te omzeilen.

Lijkt me een interessante uitdaging,

Hugo

From: Floris Looijesteijn 
Sent: Tuesday, May 21, 2013 3:43 PM
To: OpenStreetMap NL discussion list 
Subject: Re: [OSM-talk-nl] Nieuwe Waalbrug A50

Ik heb dat gedrag vaker gezien op navigatiesystemen. 

Dat je je opeens rotschrikt en snel de afslag neemt omdat je niet bekend bent 
in de buurt. 
Om vervolgens beneden weer direct de snelweg op gestuurd te worden...

Met onze data kan toch zeker een betere beslissing genomen worden.
Routers zouden kunnen kijken het aantal kruisingen.
Of gewoon een voorkeur hebben voor op dezelfde weg blijven als dat maar een 
paar procent in afstand/tijd scheelt.

Gr,
Floris




2013/5/21 Maarten Deen md...@xs4all.nl

  On 2013-05-21 12:24, Martien Scheepens wrote:

Hallo,

Op de A4 hebben we al zo'n geval: http://osm.org/go/0E4wjRnhl- [2]
Ik vraag me af wat routeplanners er mee doen.


  Kortste of snelste route, al naar gelang het algoritme.

  Zie ook http://osrm.at/2We waar de routeplanner doet of zijn neus bloedt en 
de korste/snelste route berekend via de afrit en oprit (snelheid op de op- en 
afrit is hetzelfde als op de autosnelweg).

  In jouw geval waarschijnlijk de binnenbocht, dus de linkse rijstroken.

  Maarten


2013/5/21 Maarten Deen md...@xs4all.nl


  Vandaag is de nieuwe Waalbrug in de A50 bij Ewijk geopend. Ik heb de 
nieuwe situatie zo goed mogelijk van de paar keer dat ik er de afgelopen tijd 
langs ben gekomen gemapt en de oude brug op construction gezet. Verbeteringen 
zijn uiteraard welkom.

  Misschien een punt van aandacht: hoe wordt de nieuwe situatie gemapt met 
ways: de nieuwe brug heeft 1x4 rijstroken en zal dus eigenlijk 1 way worden, de 
oude brug blijft 2x2 rijstroken hebben en zal dus 2 ways blijven?

  Maarten

  ___
  Talk-nl mailing list
  Talk-nl@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-nl [1]




Links:
--
[1] http://lists.openstreetmap.org/listinfo/talk-nl
[2] http://osm.org/go/0E4wjRnhl-

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


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





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

Re: [OSM-talk-nl] postkantoren

[Hugo Holscher]

Aangezien de Franse oplossing ook in de internationale Wiki genoemd wordt, 
zo ik die gewoon als richtlijn aannemen. Ik zie zo gauw geen bezwaren. Lijkt 
me dat we niet het wiel moeten heruitvinden.  Dank aan Cartinus om dat te 
vinden en te delen. Hugo


-Oorspronkelijk bericht- 
From: Ronald Stroethoff

Sent: Sunday, February 17, 2013 8:48 PM
To: talk-nl@openstreetmap.org
Subject: Re: [OSM-talk-nl] postkantoren

Zover ik weet zijn in ieder geval de klassieke postkantoren verdwenen, zelfs
de postbussen en antwoordnummers zijn daar verwijdert en naar andere plekken
(zoals de Gamma) verplaatst.
Andere plekken zoals de albert heijn en videotheken handelen nu zaken zoals
de verkoop van postzegels en inname van paketten af.

Cartinus wrote:


Voor zover ik weet heeft er nog niemand geprobeerd om hier consensus
over te krijgen.
_ _ _ _ _ _ _ _ _

Het hangt er vanaf wat je allemaal een amenity=post_office noemt. Alleen
de klassieke postkantoren? Of ook postagentschappen?

Zie hier de Franse oplossing:
http://wiki.openstreetmap.org/wiki/Key:post_office:type

On 02/17/2013 07:31 PM, Ronald Stroethoff wrote:

In Nederland is er nogal wat verandert wat betreft postkantoren.
Of je het leuk vind of niet, maar langzamerhand zijn alle postkantoren in
Nederland gesloten.
Het staat natuurlijk een beetje stom als in openstreetmap nog steets
postkantoren voorkomen.
Hoe gaan we daarmee om?

Ronald







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



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

[Talk-br] Como exibir bairros usando Leaflet.

[Hugo Walberto Alves]

Boa tarde,

estou usando o Leaflet para editar o estilo do OSM que estou utilizando no
meu site, porém os bairros que aparecem no OSM original não são exibidos no
mapa estilizado. Alguém pode me ajudar com isso?

Abraço,

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

Re: [Talk-br] Como exibir bairros usando Leaflet.

[Hugo Walberto Alves]

Esqueci de mencionar que estou utilizando o Leaflet juntamente com o
Cloudmade.


Em 4 de fevereiro de 2013 17:21, Hugo Walberto Alves
hwal...@gmail.comescreveu:

 Boa tarde,

 estou usando o Leaflet para editar o estilo do OSM que estou utilizando no
 meu site, porém os bairros que aparecem no OSM original não são exibidos no
 mapa estilizado. Alguém pode me ajudar com isso?

 Abraço,

 Hugo.

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

Re: [OSM-talk-nl] Religie

[Hugo Holscher]

Het gebruik van public geeft voor engels-taligen verwarring: een public 
school is een privé school.


Hugo

-Oorspronkelijk bericht- 
From: Cartinus

Sent: Saturday, January 12, 2013 5:03 PM
To: talk-nl@openstreetmap.org
Subject: Re: [OSM-talk-nl] Religie

On 01/12/2013 05:42 PM, Ronald Stroethoff wrote:

Op dit moment worden religie gebruikt voor kerken en voor begraafplaatsen.
D.W.Z. van een begraafplaats wordt verteld of deze katholiek of protestant
enz. is.
Voor scholen wordt dit niet gedaan terwijl veel scholen toch een religeuse
achtergrond hebben.
Vaak wordt dit in de naam uitgedrukt zoals Protestant christelijk
Jenaplanschool

Is het wellicht een idee om ook bij scholen de religie op dezelfde manier
zoals bij begraafplaatsen te gaan vermelden .


Prima idee en er staat je niets in de weg om hier mee te beginnen.


Letop: voor openbare scholen kan men de religie public gebruiken.
Letop: voor privescholen (zoals het lusac-college) kan men de religie
private gebruiken.


Dit is misbruik van de tag. public en private zijn geen religie. Als
de school niet op religieuze grondslag gestoeld is de religie none.

Bovendien staat het feit of onderwijs privaat is of niet haaks op
religieuze grondslag. Een katholiek seminarie is namelijk ook een
private onderwijsinstelling.

---
m.v.g.,
Cartinus

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



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

Re: [OSM-talk-nl] Wegaanpassingen via www.staatscourant.nl

[Hugo Holscher]

@Floris, Interessante vraag. Volgens mij vallen besluiten van de overheid niet 
het kopieerrecht (artikel 11). Aangezien er een besluit van een 
overheidsinstantie gepubliceerd wordt zouden we het dus mogen gebruiken zonder 
problemen. Waar je misschien wel heisa mee krijgt is de huidige gebruiker van 
deze gegevens: Andes. Die maakt er namelijk deze kaart van 
http://www.nhbereikbaar.nl/ voor de provincie NH. Wat wel eigenaardig is, is 
dat ze als basis kaart Googlemaps gebruiken. Ik vraag me af of ze al onder de 
kosten regeling van Google maps vallen. 
Hugo
From: Floris Looijesteijn 
Sent: Friday, December 28, 2012 3:52 PM
To: OpenStreetMap NL discussion list 
Subject: [OSM-talk-nl] Wegaanpassingen via www.staatscourant.nl

Hallo!

Heeft iemand al eens gekeken of wij deze informatie ook kunnen gebruiken?

http://www.nu.nl/gadgets/2992181/wegaanpassingen-sneller-navigatiesystemen.html 

Groet,
Floris



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

Re: [Talk-br] Inserções de fontes não permitidas em POA

[Hugo Walberto Alves]

Olá, eu disse coloquei as marcações dos bairros com base na posição
aproximada colocada pelo google maps, não a mesma. Para que criar uma
discussão por causa disso???



Em 20 de dezembro de 2012 12:23, Bráulio brauliobeze...@gmail.comescreveu:

 Acho que era ele que tava numa outra thread da lista perguntando por que
 os bairros que ele colocou não apareceram no mapa. Se não obteve resposta
 pode reverter ou tentar mandar email diretamente para ele.

 Mas melhor ainda seria utilizar esses dados da prefeitura [1] para colocar
 os bairros bem direitinho. Parece que há uns bairros que ainda não foram
 criados oficialmente, então tem que prestar atenção nisso (nunca fui a
 Porto Alegre, só achei isso no site da prefeitura). Pode até pedir para o
 próprio hwalves ajudar nisso.

 [1] 
 http://www2.portoalegre.rs.gov.br/spm/default.php?reg=4p_secao=229http://www2.portoalegre.rs.gov.br/spm/default.php?reg=4p_secao=229

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


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

Re: [Talk-br] Inserções de fontes não permitidas em POA

[Hugo Walberto Alves]

Pessoal,

deletei as marcações que havia colocado e estou criando novas com base nos
dados oficiais da prefeitura de Porto Alegre. Obrigado pelas dicas.

Hugo.

Em 20 de dezembro de 2012 14:04, Gerald Weber gwebe...@gmail.com escreveu:

 Oi Hugo

 a questão de onde vem os dados é muito sensível no OSM, um dos pilares do
 projeto é que ninguém possa vir a questionar a origem dos dados e vir dizer
 que copiamos sem autorização. Google Maps é um dos exemplos notórios de
 onde não podemos importar dados. Se você está se baseando em seu próprio
 conhecimento dos bairros coloque source=survey.

 Dito isto, me preocupa a grande quantidade de dados eu tenho visto sem a
 tag source por aí.

 abraço

 Gerald

 PS: é interessante notar que na legislação brasileira de direito autoral,
 a proteção de copyright de uma base de dados não se estende ao conteúdo da
 base. Por exemplo, se você faz uma base de dados de aniversários de
 pessoas, a base pode ser protegida por copyright. Mas o seu conteúdo (os
 aniversários) não. Mas o Google Maps diz textualmente que você não pode
 usar os dados deles para criar outros mapas digitais.

 2012/12/20 Hugo Walberto Alves hwal...@gmail.com

 Olá, eu disse coloquei as marcações dos bairros com base na posição
 aproximada colocada pelo google maps, não a mesma. Para que criar uma
 discussão por causa disso???



 Em 20 de dezembro de 2012 12:23, Bráulio brauliobeze...@gmail.comescreveu:

 Acho que era ele que tava numa outra thread da lista perguntando por que
 os bairros que ele colocou não apareceram no mapa. Se não obteve resposta
 pode reverter ou tentar mandar email diretamente para ele.

 Mas melhor ainda seria utilizar esses dados da prefeitura [1] para
 colocar os bairros bem direitinho. Parece que há uns bairros que ainda não
 foram criados oficialmente, então tem que prestar atenção nisso (nunca fui
 a Porto Alegre, só achei isso no site da prefeitura). Pode até pedir para o
 próprio hwalves ajudar nisso.

 [1] 
 http://www2.portoalegre.rs.gov.br/spm/default.php?reg=4p_secao=229http://www2.portoalegre.rs.gov.br/spm/default.php?reg=4p_secao=229

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



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



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


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

Re: [Talk-pt] Uso de tags

[Hugo Silva]

Boas,
Aproveito a oportunidade para relembrar o projecto
*openstreetmap.pt*lançado no SASIG5 inserido na iniciativa vamos
mapear portugal.
Este foi um dos temas focados na sessão de brainstorming realizado no
último dia do evento. A ideia (ainda por trabalhar) será a de fazer uma
lista, clara e de fácil utilização no apoio aos mapeadores no segmento de
edição. Esta lista irá conter as tags mais usadas acompanhadas de exemplos
ilustrativos da sua utilização. O objectivo será o atingir a homogeneidade
na categorização dos dados espaciais incluidos no OSM referentes ao nosso
território.

Cumps,
Hugo Silva


No dia 14 de Dezembro de 2012 00:40, Victor Ferreira 
victor.mota.ferre...@gmail.com escreveu:

 Acho que o wiki deverá ser o sitio para colocar isto para todos
 encontrarem... e tendo já editado alguma coisa por lá, estou um pouco
 aflito com fim de semestre e preparação de outro para poder ajudar
 muito nisso :-) O pouco tempo livre temsido para editar o mapa.
 QUanto ao Bridleway, embora não seja umacoisa que me pareça estar em
 lei na realidade existem bastantes cavalos e cavaleiros aqui na zona
 de Mafra e Ericeira, eventualmente alguém tem marcado os caminhos que
 são transitáveis por cavalos? Uma forma de apurar isso seria contactar
 quem editou para saber se é intencional ou só um mau entendimento do
 significado da tag.
 Victor

 2012/12/11  f.dos.san...@free.fr:
  Temos a página no wiki : http://wiki.openstreetmap.org/wiki/Portugal
 
  Estou a brincar, esta página está numa miseria, informações a mais e
 falta de estrutura. Da vontade de apagar e começar de novo.
 
 
  No que toca ao uso de tag também fico surpeendido com o uso do
 highway=bridleway, por exemplo aqui (os caminhos em verde) :
 
  http://www.openstreetmap.org/?lat=38.98917lon=-9.39413zoom=16layers=M
 
 
  Não sei se o significado bridleway pode ter uso em Portugal :
 
  http://wiki.openstreetmap.org/wiki/Pt-br:Tag:highway%3Dbridleway
 
  Francisco
 
 
  - Mail original -
  From: Duarte Carreira dcarre...@edia.pt
  To: talk-pt@openstreetmap.org, victor mota ferreira 
 victor.mota.ferre...@gmail.com
  Date: Mon, 10 Dec 2012 14:24:28
  Subject: Re: [Talk-pt] Uso de tags
 
  Victor, há alguma página onde se possa coleccionar estas dicas?
 
  Abraço,
  Duarte
 
  -Mensagem original-
 
  Date: Mon, 10 Dec 2012 09:05:59 +
  From: Victor Ferreira victor.mota.ferre...@gmail.com
  To: Lista de discuss#227,o para Portugal
  talk-pt@openstreetmap.org
  Subject: [Talk-pt] Uso de tags
  Message-ID:
  CAHXzmfQzK=
 2nd2sevhg8gra3p4dfyvftg-j2m8geng+hevs...@mail.gmail.com
  Content-Type: text/plain; charset=ISO-8859-1
 
  Ol?,
  queria s? partilhar que nas minhas edi??es detectei alguns problemas com
 tags em estradas:
  utiliza??o de tag oneway=true - recomenda-se utilizar oneway=yes
  utiliza??o de tags place em estradas - as tags place dever?o ser
 utilizadas em lugares, como entidades ponto, n?o existindo qualquer
 indica??o do seu uso em estradas (que eu conhe?a?).
  Se existirem outras opini?es digam! :-)
  J? agora proponha que se encontrarem algum tipo de problema orelatem
 aquina lista para podermos ir melhorando as nossas pr?ticas!
  Abra?o,
  Victor
 
 
 
 
  ___
  Talk-pt mailing list
  Talk-pt@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-pt
 
  ___
  Talk-pt mailing list
  Talk-pt@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-pt

 ___
 Talk-pt mailing list
 Talk-pt@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-pt

___
Talk-pt mailing list
Talk-pt@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-pt

[Talk-br] Mapa personalizado.

[Hugo Walberto Alves]

Boa tarde,

gostaria de saber se é possível eu criar um mapa personalizado usando OSM?
Eu gostaria de criar marcadores e determinar ações para quando clicados. Eu
consigo fazer isso com o Google Maps usando a API dele, como funciona isso
no OSM?
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-nl] junction= roundabaout

[Hugo Hölscher]

I do think there are situations were you want do a full roundabout.
Example: want toturn left on a road, but that is prohibited. Right is
allowed and there is a nearby roundabout. Then you will do a full-turn.
Hugo
Op 22 nov. 2012 10:03 schreef Maarten Deen md...@xs4all.nl het volgende:

 On 2012-11-22 09:41, Wolfgang Wienke wrote:

 Am 22.11.2012 07:50, schrieb Maarten Deen:

 On 2012-11-21 20:48, Wolfgang Wienke wrote:

 Am 21.11.2012 18:48, schrieb Maarten Deen:

 On 11/21/2012 06:45 PM, Maarten Deen wrote:

 On 11/21/2012 06:41 PM, Wolfgang Wienke wrote:
  Hi,
  I'm mapping in NL near Aachen. Can someone tell me, why there is
 more
  that ONE way in a dutch roundabaout?
 There isn't. A roundabout is always one way. If there are two
 directions
 it is not a roundabout but a circular road.

  Just after sending this I realized that I must have misread your
 question. You mean why most roundabouts are made up of more than one
 way.

 Initially it is because of the AND import. The AND dataset was such
 that
 between every junction of 3 or more roads there was a sperate way.

 What means the AND dataset?


 AND donated their dataset in 2007 and was subsequently integraded into
 OSM.
 http://wiki.openstreetmap.**org/wiki/AND_Datahttp://wiki.openstreetmap.org/wiki/AND_Data
 

 I do not find there any special about roundabouts. I think, that it
 is important to recognize a roundabout for navys to tell the user
 something like leave the rounabout at the second street.
 Is there no discussion in Netherlands to join the automatically
 generated part of a roundabout manually?


 No, because that is not necessary.
 The AND data was structured such that at every point where there is a
 juntion of three or more ways, a new way was created. You'll still see that
 in lots of parts of the Netherlands:
 http://www.openstreetmap.org/**?lat=51.319581lon=5.996067**
 zoom=18layers=Mhttp://www.openstreetmap.org/?lat=51.319581lon=5.996067zoom=18layers=M
 

 It is not necessary that the road Lindanusstraat is split up in 5 parts,
 but that is how the AND dataset came. You'll notice the AND_nosr_r tags on
 these ways, so you can see it came from AND that way. The same with
 roundabouts. Because every connecting road is a point where 3 ways connect,
 it was a different way.

 Routing engines have no adverse effects from this. There is no
 (sell-respecting) routing engine that will tell you to continue for 100
 metres a thousand times when the road is spilt up in smaller ways. So why
 would it do that on a roundabout?
 A roundabout is recognized by its tag: junction=roundabout. Not by its
 physical properties (a circular one-way street).

  Now it is just convenient if you have different relations (like a bus
 line) over the roundabout. Then you can indicate exactly which side a
 relation takes.

 Well, this is really not necessary because you drive the roundabout
 alwas in the same direction.
 In Germany we only have roundabouts made of ONE way. If you use the
 relation-editor of JOSM, than you can easily recgnize a roundabout.
 Would it not be easier, to use only ONE way in a roundabaout?


 I think this looks much tidier than when roundabouts are always one way.


 http://www.openstreetmap.org/**?lat=51.32506lon=5.97571**
 zoom=17layers=Thttp://www.openstreetmap.org/?lat=51.32506lon=5.97571zoom=17layers=T
 

 Also, if you make a route over a roundabout, you never use the full
 roundabout, so why would you want the full roundabout in the relation?


 Of course this is true, but I think it looks tidier the other way,
 look here. You see at once, that there is a roundabout.

 http://www.openstreetmap.org/?**lat=50.791022lon=6.059449**
 zoom=18layers=Thttp://www.openstreetmap.org/?lat=50.791022lon=6.059449zoom=18layers=T


 I don't see the difference there because it has only single ways
 connecting to the roundabout.

 But let me ask this simple question: if you go from A to B via a
 roundabout, do you traverse the whole roundabout or only a part of it? Why
 then add the full roundabout to a relation that describes the route from A
 to B?

 It is also clearer not to add the full roundabout. Take this example: 
 http://www.openstreetmap.org/**?lat=51.333905lon=5.995042**
 zoom=18layers=Thttp://www.openstreetmap.org/?lat=51.333905lon=5.995042zoom=18layers=T
 

 It is immediately clear that bus 62 goes from east to west. If you had the
 complete roundabout in the relation, the whole roundabout would be red and
 you would not know which direction the relation had.

 Regards,
 Maarten


 __**_
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-nlhttp://lists.openstreetmap.org/listinfo/talk-nl

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

Re: [OSM-talk-nl] junction= roundabaout

[Hugo Hölscher]

Agree more the exeption then the rule. But any action which prohibits
routing for this situation should be avoided,
Hugo
Op 22 nov. 2012 12:48 schreef Jo winfi...@gmail.com het volgende:

 In that case you add all the ways of the roundabout to your route
 relation. You'll have to admit it's rather the exception than the rule.

 Jo


 2012/11/22 Hugo Hölscher hugoholsc...@gmail.com

 I do think there are situations were you want do a full roundabout.
 Example: want toturn left on a road, but that is prohibited. Right is
 allowed and there is a nearby roundabout. Then you will do a full-turn.
 Hugo
 Op 22 nov. 2012 10:03 schreef Maarten Deen md...@xs4all.nl het
 volgende:

 On 2012-11-22 09:41, Wolfgang Wienke wrote:

 Am 22.11.2012 07:50, schrieb Maarten Deen:

 On 2012-11-21 20:48, Wolfgang Wienke wrote:

 Am 21.11.2012 18:48, schrieb Maarten Deen:

 On 11/21/2012 06:45 PM, Maarten Deen wrote:

 On 11/21/2012 06:41 PM, Wolfgang Wienke wrote:
  Hi,
  I'm mapping in NL near Aachen. Can someone tell me, why there is
 more
  that ONE way in a dutch roundabaout?
 There isn't. A roundabout is always one way. If there are two
 directions
 it is not a roundabout but a circular road.

  Just after sending this I realized that I must have misread your
 question. You mean why most roundabouts are made up of more than one
 way.

 Initially it is because of the AND import. The AND dataset was such
 that
 between every junction of 3 or more roads there was a sperate way.

 What means the AND dataset?


 AND donated their dataset in 2007 and was subsequently integraded into
 OSM.
 http://wiki.openstreetmap.**org/wiki/AND_Datahttp://wiki.openstreetmap.org/wiki/AND_Data
 

 I do not find there any special about roundabouts. I think, that it
 is important to recognize a roundabout for navys to tell the user
 something like leave the rounabout at the second street.
 Is there no discussion in Netherlands to join the automatically
 generated part of a roundabout manually?


 No, because that is not necessary.
 The AND data was structured such that at every point where there is a
 juntion of three or more ways, a new way was created. You'll still see that
 in lots of parts of the Netherlands:
 http://www.openstreetmap.org/**?lat=51.319581lon=5.996067**
 zoom=18layers=Mhttp://www.openstreetmap.org/?lat=51.319581lon=5.996067zoom=18layers=M
 

 It is not necessary that the road Lindanusstraat is split up in 5
 parts, but that is how the AND dataset came. You'll notice the AND_nosr_r
 tags on these ways, so you can see it came from AND that way. The same with
 roundabouts. Because every connecting road is a point where 3 ways connect,
 it was a different way.

 Routing engines have no adverse effects from this. There is no
 (sell-respecting) routing engine that will tell you to continue for 100
 metres a thousand times when the road is spilt up in smaller ways. So why
 would it do that on a roundabout?
 A roundabout is recognized by its tag: junction=roundabout. Not by its
 physical properties (a circular one-way street).

  Now it is just convenient if you have different relations (like a bus
 line) over the roundabout. Then you can indicate exactly which side a
 relation takes.

 Well, this is really not necessary because you drive the roundabout
 alwas in the same direction.
 In Germany we only have roundabouts made of ONE way. If you use the
 relation-editor of JOSM, than you can easily recgnize a roundabout.
 Would it not be easier, to use only ONE way in a roundabaout?


 I think this looks much tidier than when roundabouts are always one
 way.


 http://www.openstreetmap.org/**?lat=51.32506lon=5.97571**
 zoom=17layers=Thttp://www.openstreetmap.org/?lat=51.32506lon=5.97571zoom=17layers=T
 

 Also, if you make a route over a roundabout, you never use the full
 roundabout, so why would you want the full roundabout in the relation?


 Of course this is true, but I think it looks tidier the other way,
 look here. You see at once, that there is a roundabout.

 http://www.openstreetmap.org/?**lat=50.791022lon=6.059449**
 zoom=18layers=Thttp://www.openstreetmap.org/?lat=50.791022lon=6.059449zoom=18layers=T


 I don't see the difference there because it has only single ways
 connecting to the roundabout.

 But let me ask this simple question: if you go from A to B via a
 roundabout, do you traverse the whole roundabout or only a part of it? Why
 then add the full roundabout to a relation that describes the route from A
 to B?

 It is also clearer not to add the full roundabout. Take this example: 
 http://www.openstreetmap.org/**?lat=51.333905lon=5.995042**
 zoom=18layers=Thttp://www.openstreetmap.org/?lat=51.333905lon=5.995042zoom=18layers=T
 

 It is immediately clear that bus 62 goes from east to west. If you had
 the complete roundabout in the relation, the whole roundabout would be red
 and you would not know which direction the relation had.

 Regards,
 Maarten


 __**_
 Talk-nl

Re: [OSM-talk-nl] Het taggen van BAG data.

[Hugo Holscher]

Het viel mij op dat de gegevens van het BAG (tenminste zo als ik ze in de BAG 
viewer zie), data bevat die nog niet bestaan. Als je deze id zoekt: 
039710014064, vind je een huis en adres  in Heemstede waarvan de bouw nog 
niet eens begonnen is. Verder weet ik dat de bouw vergunning aan verandering 
onderhevig is. Gaan we met bulk up-loads nu de mogelijk toekomstige kaart van 
Nederland maken of is het wijsheid om de locaties waarvan de status is: 
“bouwvergunning verleend” er nog uit laten?

Hugo


From: Gertjan Idema 
Sent: Saturday, October 20, 2012 8:54 PM
To: talk-nl@openstreetmap.org 
Subject: Re: [OSM-talk-nl] Het taggen van BAG data.

On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote: 
Beste Gertjan e.a,

Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week 
ververst met versie 8 sept en 8 okt:
Fijn dat je meedenkt :-) 
http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml 
(Atom).
e.e.a. moet ook simpeler worden in de toekomst:
http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds

Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.


On 17-10-12 13:11, Gertjan Idema wrote:
 Er is een aantal initiatieven gaande voor het opnemen van BAG data in
 Openstreetmap.
 - ruudblank heeft veel werk verricht in Gorinchem.
 - rullzer in de omgeving Purmerend
 - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee
 (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig
aan het testen zijn.
 - en ongetwijfeld nog meer.

 Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee
 van deze discussie is om hier samen te vatten wat er tot nu toe gedaan
 en besproken is over het taggen van data afkomstig uit de BAG.
 Vervolgens hoop ik dat we het samen eens kunnen worden over een
 standaard. Deze kan dan opgenomen worden op de Wiki pagina en
 geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel
 mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat dit
 consistent gebeurt.

 Eerst maar eens een inventarisatie:

 Adres tags op pand of losse nodes
 =
 De BAG maakt onderscheid tussen panden, verblijfsobjecten en
 nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.
Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO), 
maar moet daarvan nog voorbeeld zien.
Hier is een mooi voorbeeld: VBO 034401091735 (Ambachtsweg 52, Utrecht) ik 
heb ook nog even geen
idee hoe we dit het beste in OSM zouden kunnen mappen.
Een ander voorbeeld is VBO 034410054743 (Hoogravenseweg 140A). Hier zijn 2 
panden samengevoegd en vervolgens opgedeeld in 7 verblijfsobjecten.
Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de meesten met 2 
panden per VBO. 
 Tot nu toe heb ik de adressen als volgt getagd:
 Voor panden met een enkel verblijfsobject heb ik de adres tags
 (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld
 met in tag ref:bagid het BAG id van het pand.
 Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen
 adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De
 adres tags heb ik aan losse nodes gekoppeld met in tag ref:bagid het
 BAG id van de nummeraanduiding.

 ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te
 koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van
 het verblijfsobject in de tag bag:vbo_id en op de panden het BAG id
 van het pand in bag:pand_id.

 rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met
 meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.
Een lastige, ik zou in ieder geval zo dicht mogelijk bij het BAG model 
blijven...Bijv. kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes 
zijn (plm 9 miljoen in NL!)? En gekoppeld via relaties aan Panden ? In 
het achterhoofd ook het soort gebruik van OSM adressen: Geocoders, 
Door-to-door navigation. En verder aansluiten bij algemene 
OSM-conventies voor adressen.
Relaties tussen panden en verblijfsobjecten/adressen worden voor zover ik weet 
niet gebruikt in OSM. En gezien het feit dat associatedStreet relaties amper 
gebruikt worden vanwege de complexiteit, denk ik dat een eventuele 
associatedBuilding relatie het niet gaat redden.
Voor de meeste toepassingen zal een relatie tussen pand en adres niet echt 
belangrijk zijn, hoewel Cartinus aangaf dat de relatie tussen hoofdadres en 
nevenadressen (leveranciersadressen) in de transportsector wel gebruikt wordt.



 AssociatedStreet relaties
 =
 AssociatedStreet relaties bieden veel voor en nadelen en het laatste
 woord is er nog niet over gesproken. Een voordeel dat in mijn ogen
 onderbelicht is, is het bij elkaar voegen van losse stukjes van dezelfde
 straat. Hierdoor kunnen gemakkelijke relaties gelegd worden tussen
 straten in OSM en straten uit andere bronnen. Dat gaat echter alleen
 werken associatedStreets gemeengoed zijn. Gezien de complexiteit bij het

Re: [OSM-talk-nl] wegen in drievoud

[Hugo Holscher]

Ik heb ook iets dergelijks meegemaakt. Wat ik er van geleerd heb, is een tag 
mee te geven (in bijvoorbeeld een note als dat kan), waarmee je, je eigen 
wijziging kunt selecteren en veranderen. Maar misschien had dat in dit 
specifieke geval niet geholpen.

Hugo

From: dbuss...@goudappel.nl 
Sent: Saturday, October 20, 2012 10:47 PM
To: OpenStreetMap NL discussion list 
Subject: Re: [OSM-talk-nl] wegen in drievoud

Vreemd verhaal.
Ik moest alles handmatig herstellen omdat door de dubbeling de relaties (bus en 
fietsknopen) zo in de war waren dat terugdraaien geen optie meer was. Bljikbaar 
was iemand anders tegelijk of net na mij met de buslijnen bezig op mijn 
drievoudige wegen...
Nu is volgens mij alles weer netjes.
Vervolgens ben ik op zoek gegaan of er elders dubbele wegen zijn maar kon er 
geen vinden. 
Het is dus niet zo dat JOSM dit vaker doet maar een idee hoe deze changeset kon 
ontstaan heb ik nog steeds niet.


-Johan C osm...@gmail.com schreef: - 
Aan: OpenStreetMap NL discussion list talk-nl@openstreetmap.org
Van: Johan C osm...@gmail.com
Datum: 10/20/2012 04:22PM
Onderwerp: Re: [OSM-talk-nl] wegen in drievoud


Ik zie twee mogelijkheden:
1. terugdraaien
2. checken met de validator en de crossing ways handmatig verwijderen


Op 20 oktober 2012 01:31 schreef dbuss...@goudappel.nl het volgende:

  vandaag iets te enthousiast teveel tegelijk in een changeset gepackt.
  JOSM heeft daarop een aantal keren timeout gegeven tot het uiteindelijk 
gelukt is.
  Effect is nu dat alle objecten die ik geraakt heb drie keer boven elkaar in 
OSM staan.
  Weet iemand hoe dat komt en of het eenvoudig ongedaan gemaakt kan worden? 

  Het gaat om http://www.openstreetmap.org/browse/changeset/13561955

  Voorbeeld: de volgende ways (allen behorende tot changeset 13561955) zijn 
identiek:
  http://www.openstreetmap.org/browse/way/186703099
  http://www.openstreetmap.org/browse/way/186691521
  http://www.openstreetmap.org/browse/way/186693939

  Groeten, Dirk


  

 
  Disclaimer 

  De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is 
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht 
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te 
informeren door het bericht te retourneren. De afzender sluit iedere 
aansprakelijkheid uit die voortvloeit uit elektronische verzending. 
  ___
  Talk-nl mailing list
  Talk-nl@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-nl



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



 
Disclaimer 

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend 
bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u 
verzocht de inhoud niet te gebruiken en de afzender direct te informeren door 
het bericht te retourneren. De afzender sluit iedere aansprakelijkheid uit die 
voortvloeit uit elektronische verzending. 



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

Re: [OSM-talk-nl] Het taggen van BAG data.

[Hugo Hölscher]

Lijkt me de goede benadering.  Hugo
Op 21 okt. 2012 11:07 schreef Gertjan Idema g.id...@zonnet.nl het
volgende:

 **
 On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:

 Het viel mij op dat de gegevens van het BAG (tenminste zo als ik ze in de
 BAG viewer zie), data bevat die nog niet bestaan. Als je deze id zoekt:
 039710014064, vind je een huis en adres  in Heemstede waarvan de bouw
 nog niet eens begonnen is. Verder weet ik dat de bouw vergunning aan
 verandering onderhevig is. Gaan we met bulk up-loads nu de mogelijk
 toekomstige kaart van Nederland maken of is het wijsheid om de locaties
 waarvan de status is: “bouwvergunning verleend” er nog uit laten?



  Hugo


 Mijn insteek op dit moment is om gebouwen met status  Bouw gestart te
 taggen als building=construction. Voor Bouwvergunning verleend kan je
 overwegen om dat ook te doen, om wat meer informatie te geven aan een
 mapper die ziet dat er wat gaande is op een stukje grond. Daarnaast voeg ik
 een tag bag:status toe.

 Gertjan



  *From:* Gertjan Idema g.id...@zonnet.nl

  *Sent:* Saturday, October 20, 2012 8:54 PM

  *To:* talk-nl@openstreetmap.org

  *Subject:* Re: [OSM-talk-nl] Het taggen van BAG data.



  On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote:

 Beste Gertjan e.a,
 Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week ververst 
 met versie 8 sept en 8 okt:

  Fijn dat je meedenkt :-)

 http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml
  (Atom).e.e.a. moet ook simpeler worden in de 
 toekomst:http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds
 Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.

 On 17-10-12 13:11, Gertjan Idema wrote: Er is een aantal initiatieven gaande 
 voor het opnemen van BAG data in Openstreetmap. - ruudblank heeft veel werk 
 verricht in Gorinchem. - rullzer in de omgeving Purmerend - mijn eigen 
 initiatief op basis waarvan Minko (Amersfoort), PeeWee (Leusden) en 
 Sebastiaan (Oldambt) nu  kleinschaligaan het testen zijn. - en 
 ongetwijfeld nog meer. Helaas is er nog geen standaard voor het taggen van 
 BAG data. Mijn idee van deze discussie is om hier samen te vatten wat er tot 
 nu toe gedaan en besproken is over het taggen van data afkomstig uit de 
 BAG. Vervolgens hoop ik dat we het samen eens kunnen worden over een 
 standaard. Deze kan dan opgenomen worden op de Wiki pagina en geïntegreerd 
 in tools en scripts. Het doel hierbij is niet om zoveel mogelijk BAG dat in 
 openstreetmap te krijgen, maar om te zorgen dat dit consistent gebeurt. 
 Eerst maar eens een inventarisatie: Adres tags op pand of losse nodes 
 = De BAG maakt onderscheid tussen panden, 
 verblijfsobjecten en nummeraanduidingen. Een pand kan meerdere 
 verblijfsobjecten bevatten.Ja het meestvoorkomende, maar ook omgekeerd 
 (meerdere Panden bij VBO), maar moet daarvan nog voorbeeld zien.

  Hier is een mooi voorbeeld: VBO 034401091735 (Ambachtsweg 52,
 Utrecht) ik heb ook nog even geen
 idee hoe we dit het beste in OSM zouden kunnen mappen.
 Een ander voorbeeld is VBO 034410054743 (Hoogravenseweg 140A). Hier
 zijn 2 panden samengevoegd en vervolgens opgedeeld in 7 verblijfsobjecten.
 Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de meesten met
 2 panden per VBO.

  Tot nu toe heb ik de adressen als volgt getagd: Voor panden met een enkel 
  verblijfsobject heb ik de adres tags (addr:housenumber, addr:postcode, 
  addr:street) aan het pand gekoppeld met in tag ref:bagid het BAG id van 
  het pand. Voor panden met meerdere verblijfsobjecten heb ik aan het pand 
  geen adres tags gekoppeld, dit kunnen immers verschillende straten zijn. 
  De adres tags heb ik aan losse nodes gekoppeld met in tag ref:bagid het 
  BAG id van de nummeraanduiding. ruudblank heeft er in Gorinchem voor 
  gekozen om alle adressen los te koppelen van het pand. Als BAG referentie 
  gebruikt hij het BAG id van het verblijfsobject in de tag bag:vbo_id en 
  op de panden het BAG id van het pand in bag:pand_id. rullzer maakt 
  hetzelfde onderscheid als ik tussen panden met 1 of met meer 
  verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.Een lastige, 
  ik zou in ieder geval zo dicht mogelijk bij het BAG model blijven...Bijv. 
  kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes zijn (plm 9 
  miljoen in NL!)? En gekoppeld via relaties aan Panden ? In het achterhoofd 
  ook het soort gebruik van OSM adressen: Geocoders, Door-to-door navigation. 
  En verder aansluiten bij algemene OSM-conventies voor adressen.

  Relaties tussen panden en verblijfsobjecten/adressen worden voor zover
 ik weet niet gebruikt in OSM. En gezien het feit dat associatedStreet
 relaties amper gebruikt worden vanwege de complexiteit, denk ik dat een
 eventuele associatedBuilding relatie het niet gaat redden.
 Voor de meeste toepassingen zal een relatie tussen pand en adres niet echt
 belangrijk zijn, hoewel Cartinus

Re: [OSM-talk-nl] Kwaliteitscontrole uitgevoerd opfietsknooppuntennetwerken in Nederland

[Hugo Holscher]

Jo, dank, dat ziet er zeer bruikbaar uit, 
Hugo

From: Jo 
Sent: Tuesday, October 09, 2012 11:11 AM
To: OpenStreetMap NL discussion list 
Subject: [OSM-talk-nl] Kwaliteitscontrole uitgevoerd 
opfietsknooppuntennetwerken in Nederland

Ik heb m.b.v. de Overpass API alle ways gedownload die deel uitmaken van de 
Fietsknooppuntennetwerken in Nederland. Daarna heb ik mijn script laten lopen, 
met het volgende resultaat:

http://wiki.openstreetmap.org/wiki/WikiProject_Netherlands/Cycle_Routes/Node_Network

Dit zijn dus alle knooppunten waar minder dan 3 routes op toekomen/vertrekken 
en alle routes die onderbroken zijn, of die niet op 2 verschillende genummerde 
knooppunten aankomen.

Ik hoop dat jullie er wat aan hebben om de foutjes eruit te halen.

Als alle routes in een netwerk verbeterd zijn, kan ik het script uiteraard 
opnieuw laten lopen.

Waarschijnlijk doe ik de hele oefening binnen 1 of 2 maanden nog eens opnieuw.

Hier zijn ook nog wat tips te vinden om het werken met die relaties 
gemakkelijker te maken binnen JOSM:

http://wiki.openstreetmap.org/wiki/User:Polyglot/Some_ways_to_simplify_editing_cycle_node_routes_with_JOSM

Ik ben wel van plan om dat hele proces nog veel eenvoudiger te maken, zodat 
mensen niet meer met lokale bestanden hoeven te werken, zoals het daar 
beschreven staat. Daartoe wilde ik eerst zelf bestanden hebben die nagenoeg 
compleet waren. Nu ga ik dus uitzoeken wat ik moet doen om die vlot online 
beschikbaar te maken.

mvg,

Jo




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

Re: [OSM-talk] [Osmf-talk] shameless copying: still going on !!

[Hugo Holscher]

I had a look in the relevant changeset (10690450) and what you find is a huge 
amount of deleted nodes end roads, which have been replaced by new ones. 
Unfortunately are the original nodes and roads not visisble as the original 
maker has not agreed to the the ODBL and the RedactionBot has done its work. 
Even without the work of mr_Israel the nodes and roads would have disappeared.

With that this becomes a delicate legal discussion: Is deleting a set of data 
and replacing it with a new set (likely using the old data) conflicting with 
the original CC-by-SA license.
This does not mean I support copying, (I know how it feels, as my first OSM 
steps back in 2007 have mysteriously dissappeared), but before serious 
accusations of shameless copying are uttered, a solid investigation is required.
Hugo
From: Floris Looijesteijn 
Sent: Thursday, August 09, 2012 3:43 PM
To: ce-test, qualified testing bv - Gert Gremmen 
Cc: osmf-t...@openstreetmap.org ; talk@openstreetmap.org 
Subject: Re: [Osmf-talk] [OSM-talk] shameless copying: still going on !!

That's a bad thing. 
In case people want to have a look, it seems Gert means this for example:

http://www.openstreetmap.org/browse/way/150461594 

Greetings,
Floris Looijesteijn


On Thu, Aug 9, 2012 at 3:10 PM, ce-test, qualified testing bv - Gert Gremmen 
g.grem...@cetest.nl wrote:

   
  Now the map cleaning phase has been completed (according to the message of 
the day in JOSM)



  Per today 8/9/2012 I still find most of my contributions that were 
contributed under

  the CC-BY-SA license in the new map, mostly simply cutted  pasted



  This time I focused on my contributions in Israel.



  Literally all of the unique features I added to the Israel map

  have been copied by a so-called Mr_Israel, including

  the home of my family, as the only building in a circle of a few kilometers 
around

  their home. It’s impossible that Mr_Israel choose this home by hazard

  and made the effort of re-survey himself.



  Same for the red walk I actually walked and surveyed myself with a GPS,

  it still in an unmodified version in the map, just the author changed.



  Same for the numerous fish farms I drew, and apparently are the only one

  in Israel according to Mr_Israel called Fish_farming in English.

  The rest of the hundreds of fish farms in only marked is only water.



  Same for the entire kibbutz Geva , all details I draw are still there, 

  including voluntary mistakes in introduced. No changes but the name of the 
author.

  Mr_israel even for the sake of making less efforts copied the Places name Geva

  and left the original source.



  On none of the modified data a new source such as BING or GPS survey

  is mentioned, so I keep it on shameless copying !









  If this is how the OSM community respects copyrights, then I have

  to fear for the rest of the map. 







  I declare the new map  still to be  CC-BY-SA and not ODBL







  Gert Gremmen

  cetest




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






___
osmf-talk mailing list
osmf-t...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmf-talk
image001.gif___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk-nl] De Redaction BOT is klaar: zijn de data nu ODBL of moet er nog meer gebeuren

[Hugo Holscher]

Volgens de blog van Harry Wood 
(http://blog.osmfoundation.org/2012/07/26/automated-redactions-complete/) is de 
bot klaar en zijn alle data die niet onder ODBL vallen verwijderd. 

Betekent dat nu dat we over zijn op een nieuwe licentie? In dat geval dan zou 
ik wel verwachten dat de relevante web pagina’s en Copyright vermeldingen ofwel 
worden aangepast ofwel worden  verwijderd,
Hugo___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Vandalisme in openstreetmap?

[Hugo Holscher]

Ik heb even naar de geschiedenis gekeken en er staan nu alleen de originele 
door AND geleverde wegen. Als er ooit verbeteringen zijn geweest zijn die 
weer weggehaald. Er is geen BOT wijziging te zien.

Er is dus geen vandalisme, maar iets anders aan de hand.

Hugo

-Oorspronkelijk bericht- 
From: Maarten Deen

Sent: Thursday, August 02, 2012 9:13 AM
To: OpenStreetMap NL discussion list
Subject: Re: [OSM-talk-nl] Vandalisme in openstreetmap?

On 2012-08-01 20:27, Edwin Wisse wrote:

Hallo Openstreetmappers,

Ik heb iets vreemds gezien in de openstreetmap van een wijk in
Vlaardingen, bij Rotterdam. Ik ken de buurt omdat ik er opgegroeid
ben. Op de kaart viel me op dat heel veel straten in deze wijk rare
kronkels hebben. De locaties van de gebouwen klopt, maar de straten
vertonen bochten die er niet zijn. Sommige straten zijn opgeknipt.
Anderen hebben verbindingen die niet bestaan.

Omdat het een complete wijk betreft lijkt het me ook niet
waarschijnlijk dat iemand met de hand de straten heeft zitten
verleggen. Er zijn echt punten toegevoegd aan lijnstukken en die zijn
verschoven. Kan dit automatisch vernaggeld zijn? Heeft iemand dit
vaker gezien?


Ja. Het lijkt erop dat een deel van de AND import een vreemde tik heeft
gekregen. Ik heb op meerdere plaatsen gezien dat wegen op een gekke
zig-zag manier zijn neergelegd terwijl ze gewoon recht moeten zijn.
Misschien is er dan iets mis gegaan in de coördinaatconversie of is een
te lage nauwkeurigheid gebruikt?

Ik kan zo geen voorbeeld geven waar dat nog meer het geval was, maar ik
heb er een aantal gecorrigeerd.
Sowieso is er vaak een mismatch tussen de AND straten en de 3Dshapes
huizen.

Maarten


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



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

Re: [OSM-talk-nl] Andere tijden

[Hugo Holscher]

Mijn mailbox loopt vol met deze serie mails ;). De Licentie is kennelijk nog 
steeds een hot-topic.


Misschien verstandig nog even naar de bron te gaan: OSM is naar de ODBL 
gegaan omdat CC-by-SA geen bescherming bood voor databases en dat is wat de 
te beschermen kern van OSM is.


Rijst meteen de vraag: waarom geldt niet hetzelfde voor OpenTaal? Daar 
bescherm je toch ook een database en geen auteursrechten.


Als zulke databases ook een DBL zouden hebben, zou deze hele discussie 
volgens mij over zijn.


Hugo

-Oorspronkelijk bericht- 
From: Stefan de Konink

Sent: Saturday, May 26, 2012 1:34 AM
To: talk-nl@openstreetmap.org
Subject: Re: [OSM-talk-nl] Andere tijden

On 26-05-12 00:08, Gertjan Idema wrote:

- Geldt 'source=AND' ook voor de name tag van een straat?


Uiteraard, dat is de bron van de geometrie en straatnaam.


- Zo ja, mag deze straatnaam dan met vermelding van 'AND' als source
naar OpenTaal gestuurd worden.


Deze vraag kan ik zeker beantwoorden.

http://mirror.openstreetmap.nl/AND/LICENSE.TXT


De data van AND vereist CC-BY-SA, jullie leveren CC-BY. Ik acht de kans
vrij groot dat als je met de heren in Rotterdam belt, met doel etc., je
het ook nog mee krijgt onder jullie CC-BY. Ook hier: de beller is sneller.


Stefan

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



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

Re: [OSM-talk-nl] Uitsnede OSM van Amsterdam

[Hugo Holscher]

Steven,

Misschien heb je hier wat aan: http://www.maposmatic.org/

Hugoattachment: Hugo Hölscher.vcf___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

Re: [Talk-co] Como les parece esta invasion

[Hugo Gomez]

Estimados por favor les pido que no nos copien todos los correos.

gracioas por la atenciòn prestada

El 5 de noviembre de 2010 11:15, ouɐɯnH fredyriv...@gmail.com escribió:

 2010/11/5 Leonardo Gutierrez l...@autobusesaga.com:
  Yo siempre quise  conocer las ubicaciones y verlo en google earth ... tu
 las
  tienes?

 por ahí las había puesto en twitter

 salu2
  
  El 5 de noviembre de 2010 10:54, ouɐɯnH fredyriv...@gmail.com
 escribió:
 
  2010/11/5 Leonardo Gutierrez l...@autobusesaga.com:
  
   Insólito: Nicaragua invade territorio costarricense basándose en
 “error”
   de
   Google Maps
  Aja, por aqui también se cuecen habas, Colombia rompió relaciones con
  Venezuela y mostró fotos de Google.
 
 
 http://www.telesurtv.net/noticias/secciones/nota/75533-NN/colombia-presento-fotos-y-mapas-de-google-como-pruebas-de-supuesta-presencia-de-rebeldes-colombianos-en-venezuela/
  
http://dlvr.it/84XZ2
  
   --
   ___
   Leonardo Gutierrez
   Director Financiero
   Autobuses AGA de Colombia
   Duitama
   www.autobusesaga.com
   l...@autobusesaga.com
   Móvil: 3125860894
  
  
Este mensaje de correo electrónico y sus documentos adjuntos están
   dirigidos  EXCLUSIVAMENTE a los destinatarios especificados. La
   información
   contenida puede ser CONFIDENCIAL y/o estar LEGALMENTE PROTEGIDA y no
   necesariamente refleja la opinión de AUTOBUSES AGA DE COLOMBIA LTDA.
 Si
   usted recibe este mensaje por ERROR, por favor comuníquese
   inmediatamente al
   remitente y  ELIMINELO ya que usted  NO ESTA AUTORIZADO al uso,
   revelación,
   distribución, impresión o copia de toda o alguna parte de la
 información
   contenida.
  
   ___
   Talk-co mailing list
   Talk-co@openstreetmap.org
   http://lists.openstreetmap.org/listinfo/talk-co
  
  
 
 
 
  --
  http://GaleNUx.com http://galenux.com/ es el sistema de información
 para la salud
 
 
 --///--
  Teléfono USA:  (347) 688-4473 (Google voice)
  skype: llamarafredyrivera
 
  ___
  Talk-co mailing list
  Talk-co@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-co
 
 
 
  --
  ___
  Leonardo Gutierrez
  Director Financiero
  Autobuses AGA de Colombia
  Duitama
  www.autobusesaga.com
  l...@autobusesaga.com
  Móvil: 3125860894
 
 
   Este mensaje de correo electrónico y sus documentos adjuntos están
  dirigidos  EXCLUSIVAMENTE a los destinatarios especificados. La
 información
  contenida puede ser CONFIDENCIAL y/o estar LEGALMENTE PROTEGIDA y no
  necesariamente refleja la opinión de AUTOBUSES AGA DE COLOMBIA LTDA. Si
  usted recibe este mensaje por ERROR, por favor comuníquese inmediatamente
 al
  remitente y  ELIMINELO ya que usted  NO ESTA AUTORIZADO al uso,
 revelación,
  distribución, impresión o copia de toda o alguna parte de la información
  contenida.
 
  ___
  Talk-co mailing list
  Talk-co@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-co
 
 



 --
 http://GaleNUx.com http://galenux.com/ es el sistema de información para
 la salud

 --///--
 Teléfono USA:  (347) 688-4473 (Google voice)
 skype: llamarafredyrivera

 ___
 Talk-co mailing list
 Talk-co@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-co




-- 
*HUGO GOMEZ NIETO
COORDINADOR NACIONAL DE TIERRAS
MERCY CORPS*
Direcciòn: Calle 107 N0 8a 23 - Bogotà D.C. Colombia
E-mail: hgo...@co.mercycorps.org
Celular 320.865.33.37
Tel. 215.02.00 ext. 117 / Fax 108
Skype: hgomez10
www.mercycorps.org
www.mercycorps.org.co
www.mercycorps.org.uk
___
Talk-co mailing list
Talk-co@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-co