Re: [Talk-es] Bar tradicional -> ¿ amenity=pub o amenity=bar ?

[andrzej zaborowski]

Hola,

Pues no estoy de acuerdo, la palabra pub es una palabra inglesa porque
las etiquetas vienen en ingles, pero un nativo de esta lengua describe
con ella toda la categoria de establecimientos para los que no tiene
otro nombre.  Y en osm tambien etiquetara con amenity=pub las
cervecerias, bodegas, tavernas, beer garten, izakayas, etc.

En España estos establecimientos no se llamaran p.e. Pub Juanito sino
Bar Juanito porque los nombres no vienen en ingles.  Pero las
etiquetas OSM si.  Claramente las etiquetas estan diseñadas para ser
utilizadas en todo el mundo.

Lo veo similar a como en español te puedes referir con chorizo a todo
tipo de salchichas alemanas o inglesas (no es muy correcto pero no se
me ocurre mejor ejemplo), pero si hablando en aleman usas la palabra
"chorizo" esta claro que te refieres a algo tipico español.

Saludos

2017-06-21 20:35 GMT+02:00 Uranzu :
> Hola,
>
> Coincido con Daniel e Ivan.
>
> Tengo meridianamente claro que un pub es un establecimiento típico de UK,
> Irlanda, Canadá, Australia y poco más (leído en la Wikipedia) en el que se
> sirven principalmente cervezas, y tiene un aspecto tradicional inglés. Ese
> tipo de establecimiento se ha exportado a todo el Mundo conservando dichas
> características y su nombre original: “pub”. Apenas he viajado pero juraría
> que si preguntas en cualquier país de cualquier continente qué es un pub te
> lo describirán como lo he hecho. Por tanto, opino que el etiquetado de
> amenity=pub debería limitarse única y exclusivamente a este tipo de
> establecimiento. Lo contrario solo crearía confusión.
>
> ¿Qué es lo básico en un bar?: la venta de bebidas alcohólicas para su
> consumo en el lugar, y eso es lo que hacen nuestros bares, aunque también
> sirvan desayunos por la mañana. Quizás habría que replantearse el etiquetado
> o añadir subetiquetas como se ha comentado.
>
> Un saludo
>
>
>
> --
> View this message in context: 
> http://gis.19327.n8.nabble.com/Bar-tradicional-amenity-pub-o-amenity-bar-tp5876448p5898232.html
> Sent from the Spain mailing list archive at Nabble.com.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es

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

Re: [Talk-es] Bar tradicional -> ¿ amenity=pub o amenity=bar ?

[andrzej zaborowski]

Este paragrafo de la wiki parece ser un comentario linguistico sobre
una coincidencia de palabras, no veo que invite a usar la etiqueta
amenity=bar para los bares "mediterraneos".

Entiendo lo que dices de que el hecho de que el etiquetado generalice
un poco la informacion sobre los puntos de interes es una ventaja, y
tampoco estoy seguro si es buena idea crear un valor de amenity=
completamente nuevo.  Pero en este caso, el de los cuatro o cinco
tipos de amenities donde puedes tomarte una cerveza, hay ya un sistema
de etiquetado algo detallado y bien establecido (porque para los
britanicos que crearon el proyecto era importante) y hay que seguirlo.
Los bares españoles tambien se pueden dividir en varios subtipos y
cada uno de ellos mas o menos corresponde con alguna de las etiquetas
ya existentes.

La pagina de wiki citada incluso dice que el cafe juega un papel mas
importante que la cerveza en muchos de los bares y muchos de ellos
realmente son medio amenity=cafe y personalmente he usado esta
etiqueta en algunos casos y todavia lo veo correcto.  Otros bares
corresponden con amenity=restaurant o pub (que en general tienen
bastante en comun y creo que hay alguna ambiguedad en todo el mundo),
y otros, los bares de copas, con amenity=bar.

El hecho de que la etiqueta sea textual en vez de ser un numero como
en los mapas antiguos para Garmin, y que justo diga "bar" no deberia
influir en su uso.  Por otro lado conviene tener una definicion simple
de lo que esta etiqueta significa y asumir que corresponde con la
palabra española bar lo simplifica bastnate.  En fin no una solucion
perfecta.

Saludos

2017-06-20 20:51 GMT+02:00 dcapillae :
> La página en inglés para "amenity=bar", en su edición actual (20/06/2017),
> dice que:
>
> «En los países mediterráneos, la palabra "bar" tiene un significado
> diferente (aunque esto no significa necesariamente que la etiqueta deba
> aplicarse de forma diferente). Allí un bar es parte integral del estilo de
> vida. Se va por la mañana a desayunar, en el almuerzo sirven comidas
> sencillas, durante todo el día (si no se cierra después del almuerzo) la
> gente lo usa para tomar un café rápido y por la noche es un lugar de
> encuentro para tomar un aperitivo antes de la cena. Algunos abren por la
> tarde y durante la noche, aunque la mayoría cierran por la noche, algunos
> venden también tabaco, caramelos y sellos. A diferencia de un /pub/, este
> tipo de bar está abierto para el desayuno y el café juega un papel mucho más
> importante que la cerveza».
>
> La documentación de la etiqueta invita a usarla indistintamente para bares
> en cualquier parte del mundo. Además, relaciona las diferencias existentes
> en los países mediterráneos con nuestro "estilo de vida", esto es, con
> nuestra cultura y nuestras costumbres. Yo comparto esta forma de verlo, y
> creo que resulta muy útil para resolver problemáticas semejantes con otros
> tipos de etiquetas que estén relacionadas con costumbres culturales.
>
> Sinceramente, no veo la necesidad de crear algo nuevo. Todos sabemos que un
> bar en España es diferente de un bar en Inglaterra. Los ingleses también lo
> saben. Nadie debería extrañarse si al entrar en un local etiquetado con
> "amenity=bar" en España no encuentra el típico bar inglés. Lo contrario
> sería lo extraordinario.
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> View this message in context: 
> http://gis.19327.n8.nabble.com/Bar-tradicional-amenity-pub-o-amenity-bar-tp5876448p5898171.html
> Sent from the Spain mailing list archive at Nabble.com.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es

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

Re: [Talk-us] Is this a bad import or an experiment?

[andrzej zaborowski]

On 23 March 2017 at 17:19, Eric Ladner <eric.lad...@gmail.com> wrote:
> On Thu, Mar 23, 2017 at 9:25 AM andrzej zaborowski <balr...@gmail.com>
> wrote:
>> Unfortunately it looks like someone has started deleting the areas you
>> found, I looked at a random neighborhood and they were still visible
>> in the tiles but the map data shows only the small ones, now
>> unconnected to anything as the bigger ones are missing.  Haven't
>> looked at the edits history.
>>
>
> Nobody objected so I'm going through the area and removing the small
> driveway areas and replacing larger ones with service roads and/or parking
> areas as appropriate.

Ah I now see where you proposed this.  You should first contact the
original authors in any case.

It is a shame to lose all the work done when it is easy to retag
properly.  On the other hand it didn't seem too precise and could be
easier to replace than improve.  In any case I wouldn't delete it
before having something to replace the data.  It is orthogonal to the
highway centerlines -- one can exist without the other but eventually
both are useful and both will be added at some point.

Best regards

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

Re: [Talk-us] Is this a bad import or an experiment?

[andrzej zaborowski]

Hi,

On 22 March 2017 at 19:41, Eric Ladner  wrote:
> On Wed, Mar 22, 2017 at 1:07 PM Mike N  wrote:
>> On 3/22/2017 2:02 PM, Kevin Kenny wrote:
>> > Are small driveways offensive, or is it just the polygonal ones that
>> > don't connect to anything?
>>
>> To me, it's just the disconnected polygons.   Small driveways don't hurt
>> anything, and can only provide information such as telling self-driving
>> cars which driveway to pull into.
>
> Really, any "highway=*" drawn as an outline rather than a center line is a
> problem.   Routers and other processing code expects to follow the way
> segments, not honor its area as somewhere you can drive.

The current most popular tag for this is area:highway I believe and
there's quite a lot of area mapping going on in OSM now, and there are
some potential uses in addition to rendering.  Originally the
highway=* tag plus area=yes was used but that was problematic for
various reasons including confusing routers that don't support the
area mapping (all the popular ones..) and they have been long
retagged.  Note that the area:highway polygons are not supposed to be
connected to the centerlines, only between themselves.

http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway

Unfortunately it looks like someone has started deleting the areas you
found, I looked at a random neighborhood and they were still visible
in the tiles but the map data shows only the small ones, now
unconnected to anything as the bigger ones are missing.  Haven't
looked at the edits history.

Best regards

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

Re: [Talk-pe] Satélite PeruSat-1

[andrzej zaborowski]

Hola,

2016-08-08 20:22 GMT+02:00 Johnattan Rupire :
> Este lanzamiento es más que una importante oportunidad para OSM en Perú,
> alguno tiene más información al respecto? alguien sabe por ejemplo, qué
> pasará con los productos de este satélite? con las imágenes y demás
> elementos que pueda captar? estarán disponibles para la ciudadanía?

En la COP-20 habia preguntado acerca de lo que iba a pasar con estos
productos en el puesto de CONIDA y me habian dicho que serian
accesibles para instituciones del estado y se venderian a terceros con
una licencia no abierta.  En principio como los ortofotomapas de
estado en otros paises en los años 90-2000, no han sacado conclusiones
del hecho de que muchos paises ya abrieron estos recursos :(

Saludos

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

Re: [Talk-es] Bar tradicional -> ¿ amenity=pub o amenity=bar ?

[andrzej zaborowski]

2016-06-26 12:57 GMT+02:00 Jorge Sanz :

>
>
> 2016-06-26 12:41 GMT+02:00 Iñaki :
>
>> Buenos días:
>>
>> En relación con qué es un bar, nos podremos pasar la vida discutiendo
>> y alguien que vive en Vigo no tendrá la misma definición que quien vive en
>> San Sebastián, Barcelona o Sevilla. Así que, ¿por qué no hacemos caso a lo
>> que dice el Diccionario de la RAE. Nos guste o no ES LA MÁXIMA AUTORIDAD en
>> cuanto a definiciones en español. Aunque estemos en desacuerdo, toca
>> aceptar, y ya discutiremos sobre otro tipo de establecimientos similares,
>> pero lo que  es bar está definido. Y, por supuesto que, nos guste o no, la
>> RAE está por encima de todas las Wikipedias que pueda haber sobre OSM.
>>
>>
(respondiendo a Iñaki)
En este caso la definicion formal podria servir para el que vaya a
documentar el etiquetado en el wiki en español.  Pero, no influira en el
etiquetado porque etiquetamos lo que estos Puntos de Interes oferecen y
como funcionan.  Por ejemplo un criterio para amenity=restaurant si
recuerdo bien era que tenga camareros y da igual si el lugar tiene en su
nombre Bar, Sidreria, Fast Food, etc.


> Esa afirmación es muy peligrosa porque va contra la esencia de OSM, que es
> encontrar un vocabulario común para nuestra realidad habitual e
> implementarlo en una base de datos geográfica que podemos explotar de forma
> homogénea. Si cada mapper aplica ciegamente el criterio de su lenguaje sin
> buscar un consenso en la comunidad, OSM pierde totalmente su sentido.
>
> Como comentaba Miguel arriba, el lenguaje en el que se implementan las
> etiquetas es el inglés y esas etiquetas ya están establecidas y
> consensuadas por la comunidad en una discusión que si bien puede retomarse
> en cualquier momento, ha de hacerse en el foro y según los procedimientos
> que la propia comunidad ha aceptado.
>

En proyectos similares a OSM pero mas antiguos y que nunca llegaron a este
nivel de desarrollo, se usaban los codigos numericos de Garmin en vez de
etiquetas textuales.  En los editores OSM tenemos los presets que estan
traducidos a cada lenguaje junto con la interfaz de usuario y ocultan las
etiquetas que hay por debajo.  Las etiquetas hay que tratarlas como estos
codigos y no hacer mucho caso al significado de la palabra que forma la
etiqueta porque incluso en los paises de habla inglesa ocurren estas dudas
por intentar interpretar literalmente la etiqueta.

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

Re: [Talk-es] Bar tradicional -> ¿ amenity=pub o amenity=bar ?

[andrzej zaborowski]

Hola Alejandro,

Pienso lo mismo acerca de amenity=bar y lo tengo en mi lista de cosas
con las que tener cuidado etiquetando.  Lo que no tengo claro es en
que grado corresponde amenity=pub con los bares ya que los pubs no son
lugares tan tipicos para ir a desayunar por ejemplo (o ni siquiera
abren hasta por la tarde).  En fin no hay una correspondencia perfecta
pero en en algunos casos se podria considerar amenity=cafe por
ejemplo.

Saludos

2016-06-25 17:04 GMT+02:00 Alejandro S. :
> Buenas tardes,
>
> Llevamos un rato discuitiendo Carlos Tapia y yo por el grupo de Telegram si
> los bares tradicionales en España se deberían etiquetar con amenity=pub o
> amenity=bar.
>
> Yo opino que la etiqueta amenity=pub [0] se corresponde mejor con un bar
> tradicional, en general es un ambiente relajado, dan comida y te puedes
> sentar, en contraposición con amenitiy=bar [1] que en general se se refiere
> a un establecimiento donde solo venden bebidas, tienen ambientes más
> ruidosos, musica, hay que estar de pie, etc. lo que en España llamamos bar
> de copas.
>
> Carlos discrepa.
>
> La wiki refleja que en los países mediterráneos se puede usar amenitiy=bar
> para los garitos tradicionales, pero yo creo que esta excepción no favorece
> el uso de los datos de OSM al hacer que esa etiqueta no tenga un uso
> homogéneo en todo el mundo y además hace que no se puedan mapear bares de
> copas en los países mediterráneos :/
> Esa excepción fue añadida por un usuario en 2009 [2] y no se si fue
> consensuada adecuadamente.
>
> [0]: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpub
> [1]: http://wiki.openstreetmap.org/wiki/ES:Tag:amenity%3Dbar
> [2]:
> http://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dbar=prev=331228
>
> ¡Salud y libertad!
> Alejandro Suárez
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>

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

Re: [Talk-es] Visualización para ver carriles pintados.

[andrzej zaborowski]

Hola,

Creo que a base de solo lanes=* no conseguiras mucho, existe un esquema de
etiquetado mucho mas detallado y que se presta a renderizado guapo y creo
que se empieza por area:highway=* y luego algunas etiquetas mas.

Mira si te sirve lo que muestra osm2world (ejemplo sacado de los foros:
http://maps.osm2world.org/?zoom=18=49.44843=11.06507=B0TTFF)

El mas completo y guapo que habia visto era http://osmapa.pl/w/area/
(ejemplo foros..
http://osmapa.pl/w/area/?lat=53.49898=14.48022=18=
http://osmapa.pl/w/area/?lat=51.10779=17.03854=20=FBoPRQEGs)
pero cubria partes de Alemania y Polonia, las regiones que le hayan pedido
al autor.  Y parece que el autor se esta tomando ahora un descanso y han
dejado de funcionar algunas cosas, entre ellas justo no me muestra ahora
miso las marcas de los carriles.

Luego me parece que tambien existia algun plugin para JOSM que lo mostraba
en vivo pero que era menos completo.

Saludos

2016-03-28 18:19 GMT+02:00 Alejandro Moreno Calvo :

> Lo que quiero es que a partir de los datos de OSM me salga un mapa
> parecido a esto
>
> [image:
> http://www.formacionyeducacionvial.com/wp-content/uploads/carril-de-deceleracion.jpg]
>
> El 28 de marzo de 2016, 18:03, El fotógrafo giróvago <
> elfotografogirov...@gmail.com> escribió:
>
>> ¿Configurando un WMS sobre los datos con esa regla no obtendrías lo que
>> pides? No se si te estoy entendiendo bien.
>>
>> El 28 de marzo de 2016, 16:00, Alejandro Moreno Calvo 
>> escribió:
>>
>>> Estoy buscando algún programa o web que a partir de los datos de
>>> Openstreetmaps permita muestre el número de carriles, es decir, si una
>>> línea está mapeada como lanes:2 que se vean dibujados los 3 carriles
>>> separados con sus líneas discontinuas.
>>> ¿Sabéis si existe algo cómo lo que pido?
>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-pe] Charla OSM en Huacho

[andrzej zaborowski]

Hola Manuel y hola Alfonso,

Estoy ya en Lima (hasta el 31).

Alfonso, lo siento, no habia visto tu mensaje -- gmail indica algun
problema de autenticacion de yahoo.com y lo clasifica Spam sin
posibilidad de cambiarlo.

Felices fiestas

2015-12-25 12:33 GMT-05:00 Argentina en Python
<argentinaenpyt...@openmailbox.org>:
> El 13/12/15 a las 19:20, andrzej zaborowski escribió:
>>
>> Este martes 15 mas o menos a la 1 de la tarde (queda por confirmar la
>> hora) haremos un pequeño taller de mapeo en OpenStreetMap
>
>
> Yo soy Argentino y estoy yendo hacia Ecuador en auto. Llegué hace 3 días a
> Huacho. ¡Me hubiese encantado participar y/o conocerte!
>
> Si estás en Huacho todavía estaría bueno juntarnos. Yo me quedo aquí hasta
> el 7 de Enero.
>
> ¡Saludos!
>
> --
> Manuel Kaufmann
> -- http://argentinaenpython.com.ar/
>
>
> ___
> Talk-pe mailing list
> Talk-pe@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pe

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

Re: [Talk-pe] Charla OSM en Huacho

[andrzej zaborowski]

Gracias Johnattan.

Para resumir un poco, a falta de coneccion internet en el aula solo
fue una presentiacion.  En teoria se habia publicado el programa de la
jornada de talleres pero creo que solamente en la red interna porque
no lo encontre.  El programa se ha seguido de una manera caotica, asi
que mejor asi ;)  Me informan que el 8 de junio, el Dia del Ingeniero,
es un evento importante en esta universidad y sera una oportunidad
para dar a conocer OSM mas, querran invitar a algun ponente.

Saludos

2015-12-15 14:36 GMT-05:00 Johnattan Rupire <jarja...@riseup.net>:
> Hola Andrzej,
> qué bien la reunión, espero que alguien haya podido participar! hay algún
> link donde hay más info? al menos para linkearla al blog...
> Saludos y bienvenido a Perú!!
>
> El 14/12/15 a las 01:20, andrzej zaborowski escribió:
>>
>> Hola a todos,
>>
>> Este martes 15 mas o menos a la 1 de la tarde (queda por confirmar la
>> hora) haremos un pequeño taller de mapeo en OpenStreetMap en el curso
>> de una actividad de tres dias que llaman Event System en la
>> Universidad Nacional en Huacho.  Si hay algun mapero interesado en
>> asistir al taller para ayudar con su experiencia, les animo.
>>
>> Estoy en Peru de viaje y la idea del taller ha salido porque iba a
>> estar en es evento tambien por otros motivos.  He mapeado en Peru
>> antes pero no es mucho y no conozco a la comunidad OSM de aqui.
>>
>> Saludos
>>
>> ___
>> Talk-pe mailing list
>> Talk-pe@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-pe
>
>
> --
> Johnattan Rupire
> @johnarupire
> http://nomadas.ourproject.org
>
>
>
> ___
> Talk-pe mailing list
> Talk-pe@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pe

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

Re: [Talk-es] Infraestructura para render propio de osm

[andrzej zaborowski]

Hola Alejandro,

Es una muy buena idea y es un gran pedazo de hardware que teneis ahi.
Pongo algunas cosas que se me ocurren:

* es una pena que el hardware este infrautilizado.  Si teneis localizada
una fuente de estos alimentadores a 80€, estupendo.  Una busqueda rapida en
aliexpress muestra que son dificiles de conseguir a estas potencias y
llegan a 200 euros (eso en formato PC, si necesitais formato rack puede ser
mas dificil).  Esto me lleva a pensar que en un servidor de mapnik lo mas
importante para el rendimiento es la cantidad de memoria y rendimiento de
los discos, con lo cual aunque corran con solo un procesador, puede ser
suficiente y podrian quizas alimentarse mas facilmente.

* un mapa con una base de datos limitada puede correr en un hardware
bastante mas limitado, principalmente necesita el trabajo del administrador
(y el cartografo que cree el estilo grafico) y donde hospedar la maquina.

* dependiendo de los recursos que tengais se podria dedicar una maquina
para que forme parte del Content Delivery Network de OSM administrado por
la OSM Foundation ayudando a hacer mas fiables sus servicios. Por lo visto
las conecciones al tile.openstreetmap.org desde España actualmente las
gestiona el nodo frances (
http://dns.openstreetmap.org/tile.openstreetmap.org.html)

Saludos


2015-11-07 23:22 GMT+01:00 Miguel Sevilla-Callejo :

> Hola Alejandro,
> A mi me parece una idea estupenda!
> ¿Cómo podríamos gestionar la colecta/crowdfunding para financiar, al menos
> una fuente de alimentación?
> ¿Alguien sabe si desde la asociación de OSM-es se podría gestionar el
> asunto?
> Un saludo
> Miguel
>
> *[image: Geo]**Miguel Sevilla Callejo*
> *Doctor en Geografía | Doctor in Geography*
> *Consultor freelance e investigador | Freelance Consultant & Researcher*
> Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza | Fellow at
> the Pyrenean Institute of Ecology - Spanish National Research Council
> Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
> Professional Association of Geographers
> Web: http://bit.ly/sevillacallejo 
>
> 
>
> 2015-11-07 19:22 GMT+01:00 Alejandro S. :
>
>> Buenos días,
>>
>> Estábamos comentando en el grupo de telegram sobre la posibilidad de
>> montar en algún sitio una renderización con las plazas de parking ya que
>> [0] no genera tiles con todos los niveles de zoom.
>> Como miembro de Púlsar (Asociación de Software Libre de la Universidad de
>> Zaragoza)[1] y tesorero de la misma pongo a disposición una serie de
>> máquinas. El problema es que están averiadas :(
>> Os pongo en antecedentes:
>> Hace 3 años y medio el BIFI[2], que es un Instituto de Investigación de
>> aqui, nos donó 10 servidores dual Xenon (Intel(R) Xeon(TM) CPU 3.40GHz)[3]
>> porque para ellos se les quedaban pequeños pero siguen siendo buenas
>> máquinas.
>> En sus día nos planteamos utilizarlos para montar un "mirror" de OSM
>> donde subir las importaciones de cat2osm y revisarlas antes de subirlas a
>> OSM de verdad. Pero resultó que las fuentes de alimentación estaban mas
>> cascadas de lo que parecía y empezaron a romperse.
>> Como son unos bicharracos con dos Xeones cada uno pues necesitan fuentes
>> buenas de 800W. En la asociación no disponemos de dinero para comprar
>> nuevas fuentes (intentamos conseguir que el Servicio de Informática o el
>> Vicerrectorado de Estudiantes nos diera dinero o las fuentes directamente
>> pero no conseguimos nada) y ahí quedo la cosa.
>> Actualmente solo funcionan 2 de las 10 maquinas. En su día presupuestamos
>> cada fuente de alimentación en 80€, parece que actualmente están más
>> baratas.
>> Con una fuente más ya podríamos poner en marcha un mapnik.
>>
>> Hemos comentado en el grupo que si hay interés en montar el render o
>> algún otro proyecto concreto se podría hacer un colecta para cubrir el
>> gasto de las fuentes de alimentación entre todos y dales un buen uso a esas
>> máquinas :)
>> ¿Que os parece la idea?
>>
>> Saludos,
>>   Alejandro Suárez
>>
>> [0]: http://parking.crite.net
>> [1]: http://pulsar.unizar.es/
>> [2]: http://bifi.es
>> [3]: http://bifi.es/es/component/jumi/articulo?id=39
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Tramos de carreteras

[andrzej zaborowski]

Hola,

Travelling Salesman parece que tiene una libreria para eso:
http://wiki.openstreetmap.org/wiki/Traveling_salesman

OsmAnd tambien usa Java, no se si lo puedes acceder como libreria
desde otro programa.

Y luego JOSM tiene algun algoritmo para bajar datos dentro de alguna
distancia de una ruta gpx.

Saludos

2015-10-16 10:57 GMT+02:00 Victor Zamora :
> ¿Y existe alguna librería en JAVA que pueda utilizar para obtener
> directamente la ruta en coordenadas dando un punto inicial y un punto final?
>
> El 16 de octubre de 2015, 10:46, Moises Arcos 
> escribió:
>>
>> Tienes un listado en la wiki
>>
>> http://wiki.openstreetmap.org/wiki/List_of_OSM-based_services#Routing
>>
>> El 16 de octubre de 2015, 10:16, Victor Zamora 
>> escribió:
>>>
>>> Buenos días,
>>>
>>> ¿Hay algún servicio de routing basado en osm aparte de OSMR?
>>>
>>> Un saludo.
>>>
>>> El 15 de octubre de 2015, 12:51, Alejandro S. 
>>> escribió:

 Hola!
 Tal vez lo más sencillo es que miréis si algún servicio de routing
 basado en osm permita exportar la ruta, de esa manera obtienes una 
 carretera
 de un punto A a un punto B.

 Saludos


 On Fri, Oct 9, 2015, 11:21 Victor Zamora  wrote:
>
> Hola a todos,
>
> Soy alumno de una universidad y estoy trabajando en un simulador de
> conducción como parte de mi tfg. Necesitamos simular entornos reales en
> carreteras, y para ello decidimos utilizar osm. Me preguntaba si se 
> podrían
> exportar las carreteras de las rutas de un lugar de inicio hasta un lugar
> meta en algún tipo de coordenadas para la posterior traducción al lenguaje
> del simulador.
>
> Muchas gracias.
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es


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

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

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

Re: [OSM-talk] New building colour

[andrzej zaborowski]

I don't care much for specific colours but I would like the original
differentiation between building types to be kept or improved.  It was
more subtle than the proposed important buildings style, but was
nice visually and useful.

I understand this change was mostly a rewrite and so keeping previous
features was not the simplest way to go (as it normally would), but I
don't like how the change is announced in the various places as a
lightening of tone without mention of the removal of processing of the
building= tag values, or justification for this./bikeshed

Cheers

On 4 January 2015 at 18:57, Janko Mihelić jan...@gmail.com wrote:
 I like how churches have a darker colour. I'd like for schools, hospitals
 and other more important buildings to also have the darker colour.

 2015-01-04 18:34 GMT+01:00 SomeoneElse li...@atownsend.org.uk:

 On 04/01/2015 13:01, Lester Caine wrote:

 Perhaps now is the time to be looking again at real time rendering with a
 selectable style sheet, or perhaps simply a base layer on top of which
 different languages and styles can be selected.


 That sort of thing has been suggested before(1) but having configurable
 tile layers on osm.org needs someone to actually write the code to support
 that.  If you just want to create a map style for your customers, then of
 course that isn't a requirement - the tools to do it are available and the
 process to set up an OSM-a-like tile server is well documented(2).  There
 are maintenance aspects that are less well documented, but even most of that
 info's around somewhere.  I switched from mostly using the osm.org
 standard style back in the summer when it became clear that its priorities
 weren't mine.

 Cheers,
 Andy

 1) https://lists.openstreetmap.org/pipermail/dev/2014-December/028206.html
 - and probably many times previously too.

 2) See summary of links at the end of
 https://lists.openstreetmap.org/pipermail/dev/2014-December/028205.html


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



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


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

Re: [Talk-es] Fwd: Georreferenciación

[andrzej zaborowski]

2014-10-03 19:39 GMT+02:00 Cruz Enrique Borges cruz.bor...@deusto.es:
 ¿A que se puede deber esto? ¿Puede que las ortofotos estén
 mal georreferenciadas?

Como dice Cruz, las capas de Bing en muchos sitios estan
georeferenciados con varios metros de error.  En la documentacion OSM
(wiki, foros, etc.) encontraras una advertencia sobre el uso de
ortofotos en varios sitios, pero como se intenta que una persona pueda
empezar a mapear lo mas facilemente posible, muchas veces no se sigue
la regla de siempre comparar una capa con trazas GPS antes de empezar.
Luego esta regla a lo mejor ya no es actual cuando existen capas como
el catastro disponibles, de hecho se podrian usar estas capas como
referencia para las comerciales (Bing, MapBox) en tu editor -- los
editores principales te permiten ajustar la georeferenciacion de las
imagenes, y en JOSM estos ajustes se pueden subir a una base de datos
donde se comparten automaticamente con otros usarios.

Saludos

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

Re: [Talk-es] Límites administrativos

[andrzej zaborowski]

Hola Juan,

2014-10-03 14:07 GMT+02:00 Juan José Iparraguirre iparragui...@gmail.com:
 Hola a todos, estamos creando una aplicación para la que vamos a necesitar
 los límites administrativos a nivel mundial, y a todos los niveles:
 continente, país, región, ciudad, distrito, barrio

 Hemos encontrado la de GADM ( http://www.gadm.org/ ) pero vemos el problema
 de que se queda a nivel de ciudad, y necesitaríamos también los barrios.

 ¿Conocéis alguna otra que podamos utilizar que esté más completa,
 preferiblemente gratuita? Y si no, pues de pago


El GADM esta bastante bien pero tiene una licencia que prohibe uso
comercial y hay dudas acerca de como se han conseguido.  Hace un par
de años era los mas completo que existia a nivel global -- quizas hoy
en dia lo ha adelantado OSM porque se liberaron muchos datos en todo
el mundo -- en los pocos paises donde conozco OSM, efectivamente ahora
es mas completo, pero a lo mejor tampoco llega a nivel de barrios.  De
hecho el concepto de barrio no en todas las ciudades tiene limites
fijos o jerarquia fija, y la administracion funciona a nivel de
ciudad.

Saludos

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

Re: [OSM-talk] Edit with Filter On - Show new Tracing

[andrzej zaborowski]

Hi,

On 16 September 2014 22:34, Alex Rollin alex.rol...@gmail.com wrote:
 I want to trace while filters are on. What should I add to the filter so
 that my new traces will appear.

 What seems to be happening is I start to draw and the first node and the
 line are immediately filtered out.

 My filter is simple:

 add to selection
 (landuse:)

With this filter and a check in the Inverse filter columns,
appending  | (tags:0 new) makes it work for me.  Without Inverse
filter checked it works as is.

Cheers

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

Re: [Talk-es] Integración de track KML en OpenStreetMap

[andrzej zaborowski]

Hola,

Tambien te puede servir http://umap.openstreetmap.fr/, no he probado
su soporte de KML pero es uno de los formatos permitidos.  Parece que
requiere subir el fichero en vez de solo pasar su direccion.

Saludos

2014-09-02 8:37 GMT+02:00 Moises Arcos moiarc...@gmail.com:
 Buenos días,

 échale un ojo a esto [1], no sé si lo has visto antes pero te puede ser de
 utilidad, ya que se pueden hacer cosas como las que dices:

 http://osm.quelltextlich.at/viewer-js.html?kml_url=http://www.gras-linz.at/images/planb/gras-plan-b.kml

 He probado con tu KMZ y no ha funcionado, no se si será porque
 necesariamente ha de ser un kml la verdad, tampoco le he dado demasiadas
 vueltas.

 Saludos!!!

 [1] http://osm.quelltextlich.at/


 El 2 de septiembre de 2014, 2:43, Jesus Cea j...@jcea.es escribió:

 Hasta ahora estoy usando Google Maps para integrar mis rutas KML en mi
 web, pero me gustaría pasar a usar OpenStreetMap.

 La integración con Google es muy fácil: basta con llamar a una URL de
 Google indicándole dónde tenemos nuestro KML/KMZ. Por ejemplo:


 https://maps.google.com/maps?q=http://www.jcea.es/pics/picosdeurbion2013/picosdeurbion2013.kmz

 Me pregunto si hay algo comparable usando OpenStreetMap o similar por
 debajo. Necesito que la integración sea sencilla, idealmente como la que
 estoy haciendo ahora con Google.

 ¿Alguna idea o sugerencia?.

 Gracias mil.

 --
 Jesús Cea Avión _/_/  _/_/_/_/_/_/
 j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
 Twitter: @jcea_/_/_/_/  _/_/_/_/_/
 jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
 Things are not so easy  _/_/  _/_/_/_/  _/_/_/_/  _/_/
 My name is Dump, Core Dump   _/_/_/_/_/_/  _/_/  _/_/
 El amor es poner tu felicidad en la felicidad de otro - Leibniz




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



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


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

Re: [Talk-es] Añade una fuente

[andrzej zaborowski]

2014-07-03 20:09 GMT+02:00 José Luis Domingo López
openstreetm...@24x7linux.com:
 Paciencia. Yo metí en OSM muchas de las fuentes que surgieron o ya existían
 a lo largo del anillo ciclista de Madrid y la Casa de Campo.

 Por desgracia, hay mucho HP suelto por el mundo, y de aquellas sólo quedan
 operativas un puñado (el Ayuntamiento, comprensiblemente, se hartó de
 sustituir grifos, algunos sin exagerar todas las semanas).

 Así que paciencia para meter los datos Y mantenerlos al día. ¿Cómo se
 etiquetaría una fuente que está fuera de servicio por vandalismo? ¿Se añade
 algún tag para indicarlo, o se borra el objeto a la espera de que vuelva a
 estar operativa?

Es una cuestion que tambien se plantean con otras amenities tipo
restaurantes.  Yo creo que la informacion de que hay una fuente sigue
siendo util... y si la fuente deja de ser operativa y vuelve a serlo
con mucha frecuencia todavia menos sentido tiene indicar esa
informacion, es informacion temporal.  Apyo la campaña.

Por otro lado hay una ruta que hago con frecuencia, una parte pasa por
Casa de Campo, y a lo largo ninguna de la fuentes suele estar cerrada,
creo que estan mas afectadas las de las zonas del perimetro.
Saludos

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

Re: [OSM-talk] OSM France BANO project... openaddresses in France

[andrzej zaborowski]

On 16 May 2014 12:03, Martin Koppenhoefer dieterdre...@gmail.com wrote:
 So basically you can only import data that is compatible with ODbL and/or
 cc-by-sa 2.0 and which can later be relicensed. According to the CTs it
 would seem as if you could also contribute cc-by-sa 2.0-only data, which is
 in my understanding not possible as long as osmf publishes the data as ODbL.

That's not true and it has been clarified by the LWG even before the
license change process ended.  You comply with the CTs if the data you
upload is compatible with the current license (ODbL) and otherwise you
accept that what you uploaded may be removed.

Your interpretation would disallow any sources requiring attribution
which includes imports discussed at the time of the license change
(e.g. under the UK Open Government License).  If the intention was to
disallow share-alike sources, this would have been stated in the CTs.

Cheers

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

Re: [OSM-talk] Organizational mapping policy

[andrzej zaborowski]

On 15 May 2014 01:03, Frederik Ramm frede...@remote.org wrote:
 If you're in the HOT business then you might immediately see how this
 could apply to some of your projects and might make life harder. When I
 read the proposal, I think of the countless man-hours (and frustration
 and desperation and heated tempers) involved when mappers on the German
 forum once again find a strange edit pattern and over the course of days
 and hundreds of messages the truth slowly emerges.

 There's nothing punitive here; there's an attempt to make life easier
 for everyone. It is not about regulating anything - I don't think Paul
 said anything about anyone enforcing mapping rules or whatever - it is
 just about transparency and disclosure.

 If someone teaches OSM to a group of people and instructs them to set up
 an account - does it really make matters worse if you ask them to write
 one sentence on their profile page (I am Joe Smith and I am learning
 OSM in Mikel's OSM for Dummies course)? Would this not be good practice
 already, even if not expressly written anywhere?

The case of existing users mapping under the direction of others, or
users switching between their own mapping and being directed by
someone are probably relatively rare.  So the main case being new
users coming to OSM as part of a directed group, osm can maybe borrow
one or two mechanisms used on other websites:

* a field in the signup form where they can type in or select an
option about how the arrived in OSM, whose value may only be
retrievable by the DWG,

* sign-up links with an embedded referer that a workshop teacher can
create and mail to students, or if it is possible to implement
sufficiently short links then even write them on the blackboard.

Cheers

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

Re: [OSM-legal-talk] Using Google Street View to perform virtual survey

[andrzej zaborowski]

On 6 April 2014 00:04, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote:
 https://help.openstreetmap.org/questions/710/can-i-use-google-streetview-to-help-create-maps


 I see many people agree that we can use the images to access reality.  This
 does not mean we're using the images themselves, which is copyrighted work.

We'd be using the images even if we were not copying them, these are
different things.



 Also, somebody has asked Google regarding Street View. Here is Ed Parsons'
 answer: Checking the odd street names is OK. But every street name I
 would suggest
  would represent a bulk feed.


 With all due respect, this is plain wrong.  Anyone who dealt with databases
 know that a bulk load is...

This is a Google service and it's up to them to define what bulk load
is and isn't when they present you the agreement.  You can only accept
it or reject it as a whole except in very rare situations.



 And bulk feed refers to the Terms of Service: 2(e) [You may not] use the
 Products in a manner that gives you or any other
  person access to mass downloads or bulk feeds of any Content, including
  but  not limited to numerical latitude or longitude coordinates, imagery,
  and  visible map data Hope that helps.


 It says imagery.  I'm not telling to download and use the images
 elsewhere.  Reading a sign in SV photos and taking a note is different from
 copying them.

Again I think the main point is the agreement doesn't say copy, it says use.

Cheers

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

Re: [Talk-es] IDENA

[andrzej zaborowski]

He escuchado varias opiniones - en muchos casos se ha importado datos
bajo CC-By y otras licencias con el mismo requisito de atribucion
(p.e. la de los datos de Ordnance Survey en UK donde mapean varios
chicos de la OSMF).  Lo mejor en todo caso es preguntar a la fuente de
los datos si el tipo de atribucion presentado en OSM es suficiente.

Saludos

2014-02-15 14:06 GMT+01:00 k1wi k1wi...@gmail.com:
 Aparentemente no se puede utilizar datos con licencia CC-BY para importar a
 OpenStreetMap.

 http://www.openstreetmap.org/user/import_navarra/diary/20939

 
 En respuesta a
 https://lists.openstreetmap.org/pipermail/talk-es/2014-January/012146.html


 Date: Wed, 29 Jan 2014 18:14:20 +0100

 From: Matías Taborda Barroso taborda.barr...@gmail.com

 To: Discusión en Español de OpenStreetMap  talk-es@openstreetmap.org

 Subject: Re: [Talk-es] IDENA

 Message-ID:

   CAGwCOQPUCkiZ-s0eQ=oCu9j_4wEQgh2r8299Pg4sysb8WRgv=a...@mail.gmail.com

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


 Hola.


 Con ese tipo de licencia, si.


 Siguiendo estas directrices:

 http://wiki.openstreetmap.org/wiki/ES:Import


 El 29/01/2014 16:56, k1wi k1wi k1wi...@gmail.com escribió:


 Es posible el uso de los datos de Infraestructura de Datos Espaciales de

 Navarra (IDENA) en OSM? Están bajo licencia CC-BY 3.0


 http://idena.navarra.es/busquedas/catalog/descargas/descargas.page


 ___

 Talk-es mailing list

 Talk-es@openstreetmap.org

 https://lists.openstreetmap.org/listinfo/talk-es

  próxima parte 

 Se ha borrado un adjunto en formato HTML...

 URL:
 http://lists.openstreetmap.org/pipermail/talk-es/attachments/20140129/0062e3b8/attachment.html


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


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

Re: [Talk-es] Para los que no crean que los rusos son una especie aparte

[andrzej zaborowski]

Las alturas de los edificios importantes se encuentran en wikipedia
por ejemplo, luego con una foto de distancia es cuestion de notar
proporiones y dividir la altura total.

Hace un par de años (antes de usarse building:part) hice como una
prueba un edificio en Varsovia donde vivia y luego me dio satisfaccion
verlo usado como ejemplo en una charla en el SOTM.  Ahora lo veo
mejorado, http://map.f4-group.com/#lat=52.2313220lon=21.0060609zoom=17=,
http://www.osmapa.pl/#lat=52.23178lon=21.00671z=17m=os

Saludos

2014-02-15 17:58 GMT+01:00 Rafael Avila Coya ravilac...@gmail.com:
 No sé si son una especie aparte, pero no veo la fuente de los datos por
 ningún lado...

 On 14/02/14 09:00, Ander Pijoan wrote:
 Aprendiendo cómo la gente usa los tags para 3D me he encontrado con esto :

 http://www.openstreetmap.org/#map=19/55.75245/37.62313

 Lo que se traduce en esto :

 http://map.f4-group.com/#lat=55.7525943lon=37.6228904zoom=19camera.theta=44.14camera.phi=106.857

 Y ya el valiente que quiera, que pruebe a abrirla en JOSM.

 Feliz viernes.

 --
 Ander Pijoan Lamas
 Research Assistant, Deustotech
 Computer Science Engineer
 University of Deusto

 E-mail: ander.pij...@deusto.es mailto:ander.pij...@deusto.es
 Phone: +34 664471228
 in: http://www.linkedin.com/profile/view?id=162888312


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


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

 

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

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

 http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros

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

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

Re: [Talk-es] Para los que no crean que los rusos son una especie aparte

[andrzej zaborowski]

Hola Rafael,

Wikipedia es un ejemplo, los datos pueden venir en el catastro, en
mapas de obstaculos aereos, etc., o si conoces la altura de otro
edificio cercano te da informacion del angulo de una foto aerea y asi
de los demas edificios.  O como en el caso del edifico que mapee, esta
abierto al publico y puedes subir con gps.

En principio para usar textos de wikipedia, si, que hay que cumplir
con su licencia, pero que wikipedia publique un dato (imaginate una
fecha historica) no significa que ya nadie pueda usarla.  De hecho
wikipedia tiene la politica de nunca ser fuente original de datos
asi que la atribucion aunque fuese requerida (asumiendo que existiese
ley que cubre el tipo de dato) no podria ser de wikipedia.

Saludos

2014-02-15 20:32 GMT+01:00 Rafael Avila Coya ravilac...@gmail.com:
 Hola:

 Sólo quería hacer notar que no hicieron constar la fuente. En concreto,
 y ya que dices que parte de los datos están en la wikipedia, una de las
 condiciones para usar los datos de la wikipedia es atribuir su autoría
 cuando se hacen obras derivadas de la misma, como es este caso. Por lo
 tanto al menos debería haber una etiqueta de source=wikipedia.

 Un saludo,

 Rafael Ávila Coya.

 On 15/02/14 18:26, andrzej zaborowski wrote:
 Las alturas de los edificios importantes se encuentran en wikipedia
 por ejemplo, luego con una foto de distancia es cuestion de notar
 proporiones y dividir la altura total.

 Hace un par de años (antes de usarse building:part) hice como una
 prueba un edificio en Varsovia donde vivia y luego me dio satisfaccion
 verlo usado como ejemplo en una charla en el SOTM.  Ahora lo veo
 mejorado, http://map.f4-group.com/#lat=52.2313220lon=21.0060609zoom=17=,
 http://www.osmapa.pl/#lat=52.23178lon=21.00671z=17m=os

 Saludos

 2014-02-15 17:58 GMT+01:00 Rafael Avila Coya ravilac...@gmail.com:
 No sé si son una especie aparte, pero no veo la fuente de los datos por
 ningún lado...

 On 14/02/14 09:00, Ander Pijoan wrote:
 Aprendiendo cómo la gente usa los tags para 3D me he encontrado con esto :

 http://www.openstreetmap.org/#map=19/55.75245/37.62313

 Lo que se traduce en esto :

 http://map.f4-group.com/#lat=55.7525943lon=37.6228904zoom=19camera.theta=44.14camera.phi=106.857

 Y ya el valiente que quiera, que pruebe a abrirla en JOSM.

 Feliz viernes.

 --
 Ander Pijoan Lamas
 Research Assistant, Deustotech
 Computer Science Engineer
 University of Deusto

 E-mail: ander.pij...@deusto.es mailto:ander.pij...@deusto.es
 Phone: +34 664471228
 in: http://www.linkedin.com/profile/view?id=162888312


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


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

 

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

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

 http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros

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

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


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

 

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

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

 http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros

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

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

Re: [Talk-es] imágenes satélite para editar

[andrzej zaborowski]

2014/1/27 Ricardo Sanz ricardosanz1...@gmail.com:
 Buenas,

 actualmente para editar online se dispone de las imagenes satelite de Bing.
 se podrían disponer de otras?, como por ejemplo DigitalGlobe (la usa Apple
 para su app Mapas) y está muy actualizada.

Que yo sepa las imagenes de Bing en la mayoria tambien son de
DigitalGlobe, pero seguramente menos actuales.  Por otro lado se
hablaba de que en Europa en 2013 iban a reemplazarlas por sus propias
fotos de avion (30cm/px).

Ademas del PNOA que meciona Matias mira si te aparecen otras capas
cuando abres tu zona en el JOSM, porque hay algunas mas locales.  En
las versiones recientes de JOSM se añaden automaticamente al menu.

Saludos

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

Re: [Talk-es] Drone para realizar fotos aeres

[andrzej zaborowski]

Hola,

2014/1/9 Jorge Sanz Sanfructuoso sanc...@gmail.com:
 He visto un Drone que van a sacar que cuando lo he visto he dicho yo quiero
 uno para mapear. jejeje.
 Que bien vendría para cuando no hay fotos aéreas lo suficientemente
 actualizadas.

 http://www.omicrono.com/2014/01/pocket-drone-el-drone-facil-de-manejar-y-barato-que-todos-queremos/
 http://www.kickstarter.com/projects/749707768/the-pocket-drone-your-personal-flying-robot

Improsionante tiempo de vuelo, pero tengo curiosidad/dudas si siendo
tan pequeño cargado con una camara de fotos tendria suficiente
alcance.

Cambiando un poco de tema, estoy haciendo pruebas (ya desde hace
tiempo pero avanzando muy lentamente) con un quad y tri- coptero para
finalmente hacer fotos aereas con el. Si alguien en Madrid tiene
proyectos relacionados o esta interesado podriamos unir fuerzas.

Por otro lado antes hacia fotos desde cometa (con resultados mucho
mejores) y me doy cuenta que acaba de crearse un capitulo local de
Public Lab, ofreciendose un primer taller de fotografia aerea a fin de
este mes: 
http://publiclab.org/notes/pablo/01-10-2014/balloon-mapping-workshop-in-castellon-spain-opening-a-local-chapter
por si alguien esta interesado, yo no puedo ir.

Saludos

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

Re: [OSM-talk] NYPL / map-vectorizer - An open-source map vectorizer

[andrzej zaborowski]

On 7 January 2014 14:35, Christoph Hormann chris_horm...@gmx.de wrote:
 On Monday 06 January 2014, Maurizio Napolitano wrote:
 The lab of the New York Public Library created this software
 to automate and extract gis data from scanned maps
 http://www.gislounge.com/automating-extracting-gis-data-scanned-maps/

 Note for vectorizing buildings there have also been several
 demonstrations based on potrace - which meanwhile features a GeoJSON
 backend that simplifies the process:

The problem with potrace is that it needs exact colours without the
imperfections of paper drawings and scanner noise.  I imagine the NYPL
tool is better adapted to scanned material.

I've used modified potrace to digitize cadastre data for one city
(potrace was modified to deal with huge tiled images), but later wrote
a dumb python vectoriser that outputs .osm
(https://github.com/balrog-kun/vectoriser), which has similar
limitations to potrace but it can deal with unfilled outlines and I'd
like it to detect line thickness as a next step (which sometimes
reflects building attributes).  Unfortunately it's currently tied to a
specific input tile format.  Neither potrace nor my code properly
understands dashed lines which needed a lot of manual work.

Cheers

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

[Talk-es] Ediciones en Aranjuez

[andrzej zaborowski]

Hola a todos,

Me di cuenta que en Aranjuez faltan varias calles principales y a
algunas mas no tienen conecciones correctas en los cruces o no
corresponden con las imagenes.  Al mirar el render se ve que son unos
cambios recientes ya que en algunos tiles todavia aparecen estos
elementos borrados, y hay muchas calles que cambiaron de clase
(secondary a residential).

Las ultimas ediciones pertenecen al usuario Caoval registrado la
semana pasada, pero no he mirado que otras modificaciones ha hecho.
Yo lo note al dia siguiente y le he enviado un mensaje, pero no he
recibido respuesta.  Quizas habra que revertir los changesets
completos, estan en http://www.openstreetmap.org/user/Caoval/history
por si alguien quiere mirar antes de que yo tenga tiempo.

Saludos

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

Re: [Talk-us] Public Labs/balloon mapping?

[andrzej zaborowski]

Hi,

On 28 October 2013 02:35, Ian McEwen ianmcorvi...@ianmcorvidae.net wrote:
 Hi; I've been recently looking around http://publiclab.org/, especially
 at their tools for doing ground-tethered balloon and kite mapping
 (http://publiclab.org/wiki/balloon-mapping). The bulk of the prose on
 the site seems to be activism-oriented -- documenting the BP oil spill,
 Occupy encampments, etc. As you might guess I'm more interested in the
 potential to use this for OSM, but stories of others doing that seem to
 be sparse.

 Has anyone here used balloon mapping or these tools (or similar ones)
 who can share experience, pitfalls, etc.?

I've done some kite photography around the San Francisco Bay area and
more recently one session in Seattle, but haven't had time to process
 stitch any images from within the US.  I've been following what
Public Lab / grassrootsmapping.org do, and had a chance to fly kite
with Jeff Warren and Stuart Long of Public Lab, but as you say their
process and tools are designed for activism, perhaps documentation
(historial, social, not geographical), and not exactly what we need in
OSM.  The MapKnitter tool is great for easy stitching but it's
difficult to get a precision map from it, although it surely would be
a good base for an OSM oriented tool.  In theory most of the process
can be automated away but there's a shortage of opensource tools for
that.
Public Lab generally (not always) shoot from low altitudes at high
ground resultion, thus covering small areas.  It's possible to go up
to at least 3000ft so you can actually cover a couple square miles if
you allow for a bigger angle than Google Maps etc. which is not so
much of an issue for mapping.  Going high is difficult technically and
possibly legally though, and requires great conditions.

I've done some attempts with balloon mapping and many attempts using a
cheap DIY RC platform (which is gradually improving) but I've had most
success with the kite so far.

These same methods (kites, ballons, drones) are used a lot in
archaeology with established processes, but mostly use commercial
software.

Best regards

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

Re: [Talk-es] ¿¿Algún asistente al State Of The Map??

[andrzej zaborowski]

Hola Ander,

2013/9/5 Ander Pijoan ander.pij...@deusto.es:
 Mañana vuelo hacia Birmingham un poco en representación de lo que llevamos
 haciendo todo este tiempo con OpenStreetMap y sobretodo a conocer gente y
 nuevas ideas.

 ¿Estaréis alguno por allí?

Estaré también yo, a ver si nos vemos algún día de la conferencia.

Saludos

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

Re: [Talk-us] Removing US Bicycle Route tags

[andrzej zaborowski]

On 5 June 2013 23:50, Martin Koppenhöfer dieterdre...@gmail.com wrote:



 Am 05.06.2013 um 19:20 schrieb Frederik Ramm frede...@remote.org:

  The usual OSM approach would be that if a route is signposted, then it
 can be mapped - if not, then not.


 Somehow the on-the-ground rule was extended to include what is verifiable
 on paper as well. See administrative borders for instance, they are only
 very punctually surveyable.


I think more than that the surveyable / on-the-ground criteria is extended
to things that can be surveyed by asking a local or a few locals and
getting reasonably consistent answers, even when not signposted in the
usual way.  This is sometimes not consistent with the official answers.
 This could be the case with cycling routes but also even place names and
borders.

(Not a US mapper either except when staying in the US)

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

Re: [Talk-es] Apoyo en la carga de datos masivos a OSM

[andrzej zaborowski]

Hola Rene,

2013/5/7 rmendoza rmend...@geo.gob.bo:
 Hola comunidad

 Vengo trabajando en un proyecto a nivel nacional en Bolivia y se tiene como
 objetivo subir datos a OSM, utilizando las herramientas de Postlach 2 o JOSM
 me limita a solo 2000 nodos lo cual nos limita en la subida de datos mas
 grandes, les pido por favor me puedan orientar en el proceso de carga
 masiva.

El limite que mencionas es el limite del numero de nodos en una via,
es el limite del API y es el mismo indepndiente del editor o script
que usas para subir cambios.  Existen también otros limites que se
documentan en el wiki.  En general debes asegurarte de que los datos
subidos tienen propiedades parecidas al resto de los datos OSM, es
decir no deberían acercarse al limite de 2000 nodos para facilitar la
modificación posterior por los usuarios.  Es buena idea partír las
vías en segmentos de 200-300 nodos o menos, también asegurate de que
no tienen nodos innecesarios (muy cercanos o en segmentos rectos),
JOSM tiene una herramienta simplify way para eso.

Los scripts y programas de subida de datos no deben probarse usando la
base de datos principal de osm sino se hacen pruebas en una de la
copias de la base que sirven para desarrollo, aquí tienes la lista de
las instancias actuales:

http://apis.dev.openstreetmap.org/

Aquí tienes una pagina general con instrucciones y requisitos para
hacer subidas masivas y ediciones automáticas:

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

Saludos

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

Re: [OSM-talk] OSM relation ID property in Wikidata

[andrzej zaborowski]

Hi,

On 6 May 2013 21:20, Peter Wendorff wendo...@uni-paderborn.de wrote:
 Am 06.05.2013 20:26, schrieb Tobias Knerr:
 On 06.05.2013 18:54, Peter Wendorff wrote:

 [...]
 Let's see this example: A building that was a merchants kontor a few
 hundret years ago, and now contains a museum and a restaurant, while in
 between it was - let's say - a hospital).

 That's historical mapping. The problems would be the same for e.g. the
 name. But as for the parts of the example that are not directly historic:

 No, it's not. I did not speak about mapping the hospital and the
 merchants kontor, but about wikidata entries ahout the hospital and the
 merchants kontor - and wikidata in fact includes historical entities
 like that, too.

If you're not adding those historical entities to OSM (or a similar
database like that historical osm once discussed) then there's no
issue with linking to Wikidata because there's nothing to be linked.
If on the other hand you want to add that hospital and that kontor,
then in the historical mapping schema I believe you'd add them as
separate objects with their own start_date and end_date tags so that's
what would link to wikidata (if you wanted to).



 - the merchant's person page (his office)

 Wikidata would link to their internal building item instead. Not our job
 imo.

 - the museum's page

 Can be linked using the wikidata key at the museum POI.

 - the restaurant's page

 Can be linked using the wikidata key at the restaurant POI.
 You assume here that osm has distinct objects for building, restaurant
 and museum, but often that's not the case.
 Let's say the building mainly is/hosts the museum, and the restaurant
 is a small part of it, covering a part of the building only (may be part
 of the museum, too.

If it doesn't occupy the entire building then you can probably add the
museum tag on the building geometry but later once you want to add a
wikidata tag you'd probably split it out like you'd split a street
object when you want to add an attribute that applies to a part of the
attribute.  If you're into indoor mapping then you'd draw the museum
outline separately anyway.

Or you could do namespaces, basically using the same criteria as with
different attributes.  For example opening_hours which may be
different for the museum and the building.  The mechanism can be the
same for wikidata=* as for e.g. opening_hours=* and oneway=*.

 We don't have distinct objects in OSM in every case. Without the
 restaurant, the museum and the building are the same, identical object;
 but may be divided later perhaps into two objects (where one changes
 it's semantics)

 - the architect's page

 Can be linked using the architect:wikidata key at the building.

 Now you introduce a different approach to my overall question, and start
 to use namespaces for wikidata-tags.
 So why not in general use namespaces for all (even the cases above):

 restaurant:wikidata
 museum:wikidata
 architect:wikidata
 fire1934:wikidata
 merchant:wikidata

 I think, that get's very verbose once wikidata lifts off, and I don't
 think it's a good idea.

 It could be argued that we should leave that to Wikidata, though - they
 have an architect property for buildings themselves.
 +1


 - the page of the person where the name of the building comes from

 Can be linked using the name:etymology:wikidata key at the building.
 Again, we theoretically could omit this and instead rely on Wikidata's
 named after property.

 To sum up your arguments:
 well... let's use foreign keys, but only somewhere.
 What's the rule you propose for this? when to use the wikidata-tag and
 when not?
 Is it possible to describe a rule for this? (even if we don't want to
 enforce that rule, somehow what you propose should be documented and
 therefore has to be documentable in a reasonable form).

 Perhaps look into the overpass-permanent-ID solution for that.

 In my opinion that's not really a good solution here. Manually creating
 Overpass API queries is too hard.
 That's true, but what you propose is (yet) hard, too:
 To decide where to link to wikidata and where to rely on wikidatas
 internal links requires deep knowledge about the wikidata system, which
 is IMHO not acceptable as a general precondition for mappers (whose
 majority will have to deal with that in future to keep these links
 reasonably up to date).

Again mappers are already dealing with this problem when they add
phone= or website= tags.  There's no clear criteria but it's not a a
problem specific to wikidata links.

Cheers

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

Re: [OSM-talk] OSM relation ID property in Wikidata

[andrzej zaborowski]

On 3 May 2013 22:58, Frederik Ramm frede...@remote.org wrote:
 On 03.05.2013 22:12, Eugene Alvin Villar wrote:
 The consensus was that--at least for place relations which are the
 target of the said property--OSM relation IDs are stable enough and any
 changes in IDs can be easily rectified. Wikidata is a wiki after all.

 I am less concerned about the Wikidata side - if they make a bad judgement
 then it is their mess to clean up. I am however concerned that if more
 people simply assume that the status quo is there to stay (IDs are stable
 enough), this will put pressure on *us* and limit our flexibility in the
 future.

The OSMF has sent a pretty strong message saying that object IDs are
stable enough to base impactful legal decisions on them.  It will look
silly for them to go back to the stance that IDs aren't stable after
all.

Cheers

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

Re: [OSM-talk] OSM relation ID property in Wikidata

[andrzej zaborowski]

On 3 May 2013 23:14, Frederik Ramm frede...@remote.org wrote:
 On 03.05.2013 23:08, andrzej zaborowski wrote:
 The OSMF has sent a pretty strong message saying that object IDs are
 stable enough to base impactful legal decisions on them.

 The OSMF has never sent messages saying that object IDs are stable or even
 stable enough for anything; if you interpreted any of the license change
 discussions in that way, you are mis-interpreting them.

I don't understand -- wasn't the entire process based on the
assumption that intellectual property persists as long as the object
ID persists?  Wasn't that in part your own decision?

Cheers

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

Re: [OSM-talk] OSM relation ID property in Wikidata

[andrzej zaborowski]

On 3 May 2013 23:22, Frederik Ramm frede...@remote.org wrote:
 * some objects whose ID had not changed and who had been created by someone
 who rejected the license were nonetheless kept if it could be shown that
 they had been changed in a major way since;

 * some objects that had been freshly created by people agreeing with the
 license change, but that were more or less copies of other objects from
 non-agreers, were removed even though they had a different ID.

The redaction bot code doesn't generally do that and if there were
such cases then they were an insignificant minority compared to those
where the change of the object's ID meant it was considered an
entirely different object.  It's strange that you'd negate that.


 I will not discuss this sub-thread further; object IDs are not stable and
 nothing we did during the license change is suitable as a counter argument.

The fact that the IDs are not persistent had been pointed out several
times during the process and both you and the LWG have said (this is
quite clearly stated their meeting minutes) that this isn't an issue
big enough to bother.  There were some statistics posted on the list
and on IRC (from Simon Poole) stating it affected 0.1 to 1% of the
database which is in the millions of objects range.

Cheers

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

Re: [OSM-legal-talk] OSM data on copy-protected storage

[andrzej zaborowski]

On 9 April 2013 21:43, Frederik Ramm frede...@remote.org wrote:
 The ODbL has a provision for parallel distribution in 4.7b:

 You may impose terms or technological measures on the Database ... in
 contravention of Section 4.74 a. only if You also make a copy of the
 Database or a Derivative Database available to the recipient of the
 Restricted Database ...

 So I guess they are fine; the recipient of the card (the Derivative
 Database) must have access to the data; it doesn't say how this access
 should work, i.e. the recipient has no right to an unencumbered database
 that is playable on his specific device.

 Or has he? 4.7b iii says that the unrestricted database must be

 at least as accessible to the recipient as a practical matter as the
 Restricted Database.

 - so if the recipient *only* has this special hardware device that can
 *only* play the encrypted cards, would a here's the pbf download link not
 be less accessible for him...?

Thanks for your observations.

I'll be checking with them if they can perhaps publish both raw OSM
data and a version with OSM data alone that the device can read. (I'm
not sure how that encryption works.  For example if each layer was a
separate file and the files were encrypted individually then it
shouldn't be hard to do)

However... the second piece you quote kind of makes it difficult to
make use of section 4.7b that you quote first.  Except in the cases
where anyone can produce that Restricted Database from the original
database and I imagine normally that's not the case. (?)

Cheers

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

[OSM-legal-talk] OSM data on copy-protected storage

[andrzej zaborowski]

Hi,

I'm relaying a license question from a company that collects lake
bathymetry data and sells specialised GPS devices to fishers and
sailors.  They don't make the software on those devices and have to
pay to get their data converted to the format understood by that
software.  They'd like to add layers of OpenStreetMap data to the
storage cards shipped with a new device, but they'd like to keep their
bathymetry and coastline data proprietary.  The cards are
copy-protected (encrypted, I believe).  Their question is whether
OpenStreetMap data can be distributed encrypted on those cards
together with their own data.  The company can publish, e.g. on their
website, whatever files are necessary but they can't publish the
conversion process or their own data unencrypted.

My understanding is that if their coastline data is not merged with
OSM coastline data (one or the other is shown), and if they publish
raw OSM data or information on how they extracted it, then they are
fine.  But I will appreciate any comment from someone who deals with
OSM licensing more.

Cheers

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

Re: [OSM-talk] Build your own GPS receiver

[andrzej zaborowski]

Hi Rob,

On 17 March 2013 16:26, Rob Nickerson rob.j.nicker...@gmail.com wrote:
 Hi all,

 Going back a few years before GPS was widely available in pretty much
 everything bar the kitchen sink (please do post a link if you find a gps
 enabled sink :-) ) there was some discussion about making your own GPS
 receiver. If anyone is interested in taking this on as a nice weekend
 project, I have found that adafruit have a good guide for linking a GPS
 receiver to a Raspberry Pi. All components are reasonably priced and the
 guide covers everthing except running a RPi from a battery (google will help
 here).

 http://learn.adafruit.com/adafruit-ultimate-gps-on-the-raspberry-pi/introduction

I recently had a similar thought when my friend found this:
http://emerythacks.blogspot.fr/2013/01/u-blox-pci-5s-cheap-gps-module-for-your.html

It's an $8 ready to use GPS module.  You could build a receiver with a
battery, flash storage and some sort of display for under $15 with
this.  It won't be the best precision receiver but it also won't be
much worse than current best unaugmented GPS-only receivers (with
EGNOS/WAAS).

Cheers

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

Re: [Talk-es] [Cat2Osm2] Simplificación de nodos

[andrzej zaborowski]

Hola,

2013/2/26 Ander Pijoan ander.pij...@deusto.es
 Estamos dándole vueltas a lo de simplificar nodos en zonas redonditas.
 Hemos implementado un método usando el simplificador de Geotools que hace un
 trabajo bastante bueno pero que tiene un problema que a Cruz le parece
 gordo:

 Cuando se simplifican los nodos hay extremos de edificios que ya no
 comparten nodos con las parcelas y se montan unos encima de otros.

Las imágenes no se me abren, pero he tenido un problema parecido a lo
que describes, en un programa de vectorizar imágenes. Es parecido
también a lo que pasa con al herramienta simplify way en JOSM.  La
solución simple, que creo que es la que usa JOSM, es no tocar los
nodos que forman parte de mas de una vía.  El problema con esto es que
a veces es necesario simplificar vías que comparten nodos.

Pienso que lo correcto es detectar los nodos limites de tramos
compartidos por las vías, es decir los nodos pertenecientes a mas de
una vía, pero donde el nodo siguiente o anterior ya no pertenece al
mismo numero de vías.  Lo que hay que hacer es simplificar cada uno de
estos tramos por separado, de esta manera nos aseguramos de que si el
algoritmo decide eliminar un conjunto de nodos, se eliminan los mismos
nodos en todas las vías que comparten el tramo ya que las distancias
van a ser idénticas.  A ver si lo conseguí explicar bien.

Saludos

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

Re: [Talk-us] User pxptyrone's edits

[andrzej zaborowski]

Hi John,

On 29 January 2013 03:21, the Old Topo Depot oldto...@novacell.com wrote:
 Message sent to user via osm messaging

Have you had any success communicating with pxptyrone?

If not then I think it makes sense to undelete the objects and tags
that were removed by this user.  Some of it was apparently imported
data, but a lot was user contributed or enhanced with local knowledge.

pxptyrone has 39 changesets altogether and his last 35 changesets
consist of removals, some changesets containing 1000s of objects.

Cheers

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

Re: [OSM-talk] Recent edits in the wiki / Trademark issue

[andrzej zaborowski]

On 1 February 2013 19:06, Jeff Meyer j...@gwhat.org wrote:

 The OSMF BoD is doing the job for which its members were elected. Thank
 goodness.

 There's a trademark. We've been served notice (I believe). The board has
 made a decision. The chairman of the board (probably a (tm) term...) has
 communicated this decision.

 Fine, disagree, but please disagree with a plan for how to fund your
 alternate plan, describing in detail the source of new funds or what other
 OSMF activities should be de-funded to support this plan.


I agree with what you're saying although I can't help thinking that if the
OSMF can't take the risk of having some things in the wiki, the solution,
for everyone's benefit, is to move the wiki to a server that's not paid for
by the OSMF.  I'm positive finding such a server wouldn't be difficult (in
fact the home page says it is hosted at UCL  ByteMark -- so if the OSMF is
neither hosting nor writing the content, should it accept the C+D?  The
admins *are* OSMF members, but they're not OSMF).  The OSMF has at some
point started assuming responsibility for what is being published in the
database and now on the wiki.  In the case of the database it makes sense
for someone to give some level of warranty that the data in it in fact is
legally usable, although the consequences of this step have had a terrible
effect on the map and the community so far.


 Yes, it sounds silly to trademark geocode, yes, it's a US-only thing, but
 these issues are solved in courts, with real money for real lawyers, not
 well-reasoned arguments on email threads supported by personal moral and
 ethical constructs and not law.


You know, anything someone will say, who is not the judge, is just a well
reasoned argument (or not that well reasoned) and the law will have a final
word.  Doesn't mean that someone pointing out that the law makes it
unlikely for the owner of the GEOCODE trademark to sue a company in UK, or
for it to be costly to resolve, shouldn't be listened to.

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

[Talk-us] User pxptyrone's edits

[andrzej zaborowski]

Hi,

denimboy on IRC mentioned that the label for Bakersfield, CA was
missing and a few other things had disappeared.  Harry Wood found that
Bakerfield's boundary relation was missing the actual outer ring.
This relation was edited by user pxptyrone on Nov 18 where he removed
some of its members with a comment without trees.  It seems that
almost all of this user's ~30 edits were done over a period of a few
days with this same comment and consisted of almost solely deletions
or removing attributes from objects (including names like in
http://www.openstreetmap.org/browse/way/59727184/history).  denimboy
mentions that Bakersfield had a lot of trees mapped which I guess
could be annoying since he says they were sometimes in the middle of
roads.  I haven't contacted pxptyrone but it would be great if someone
can check with him, or analyze the edits, to see if they need to be
reverted.

Cheers

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

Re: [Talk-es] [catastro] Previo de CAT2OSM2: Madrid en 5 minutos (!)

[andrzej zaborowski]

Hola,
acabo de leerme todo este hilo y el da la lista imports, y tengo dos
comentarios.

2013/1/15 Ander Pijoan ander.pij...@deusto.es:
 ...
 -Hay un parámetro nuevo Catastro3D iniciado a 0 que es el que hace que se
 obvien las distintas alturas de los edificios exportando únicamente su
 planta, es decir la unión de todos ellos.

Los tags 3d, es decir la altura, me interesan personalmente y tambien
sigo los proyectos de otras personas que se basan en esta información.
 Entonces por un lado es una pena no usar esa información del catastro
y tener que seguir añadiendola a mano (con el tag building:levels),
por otro lado es cierto que muchas veces existe una construcción que
para nosotros evidentemente forma un solo edificio pero en los datos
se partiría en varios edificios solamente porque el techo no esta al
mismo nivel en diferentes partes.  Podria usarse entonces algún
compromiso para reducir el numero de las vías pero dejando una
información orientativa de la altura.  Una idea seria usar el
promedio/la mediana de las alturas de los edificios unidos, otra idea
seria ignorar solamente la altura de las partes de un edificio con
superficie menor a X por ciento de la total o menor a X metros
cuadrados.


 -A las parcelas urbanas y masas rústicas, se les asignan todas sus
 construcciones/subparcelas internas y se crea la uníon de todas las posibles
 que tengan los mismos tags. (Así se genera únicamente la base de las
 construcciones si usamos Catastro3d=0, en cambio si usamos Catastro3d=1, los
 tags variarán por tener diferentes alturas los edificios y no los unirá). En
 el caso de que una construcción coincida 100% con su parcela, no se añade
 sino que los tags de la construcción pasan a la parcela.

Si la idea es obtener un si de la comunidad de la lista imports y de
los chicos de Data Working Group, creo mas fácil seria en el primer
paso olvidarse de la parcelas urbanas.  Unir las parcelas urbanas con
los edificios es una buena decisión, pero creo que dentro del DWG
parcela puede ser una palabra que por si misma provoca reacciones
negativas.  Para dar un poco de contexto a lo que digo, el mapear las
parcelas se ha discutido hace tiempo en la lista talk y últimamente
también en varios hilos de talk-us, con muchos argumentos a favor y en
contra.  El problema en general es con los limites de las parcelas que
no se pueden ver en el terreno, es decir las que existen porque tienen
un dueño o porque se les ha asignado algún atributo.  El argumento de
DWG, en general, es que lo que no se puede comprobar visitando el
lugar físicamente no pertenece a OSM.  Ahí siempre viene un par de
respuestas (de que entonces los limites administrativos tampoco pueden
estar en OSM, o de que en EEUU si invades un terreno de alguien te
pueden disparar aunque el limite no este marcado físicamente, y
entonces DWG responde que los limites administrativos son una
excepción y que el caso de EEUU se debería resolver usando los datos
pero sin subirlos a la bdd), y eso se repite en varios hilos.  Otro
punto es que alguna vez se habían importado los limites de parcelas
urbanas en algún área de EEUU pero con fallos técnicos, lo que también
hizo que los que proponen mas importaciones de ese tipo siempre lo
tienen difícil.

A lo mejor seria mas correcto y mas fácil para las discusiones en la
lista imports hablar solamente de usos del suelo (landuse=*) y no de
parcelas aunque, si entiendo bien, ahora con el algoritmo de unir las
parcelas, son casi lo mismo (casi, porque los polígonos landuse suelen
ser unas generalizaciones con un poco menos precisión espacial).

Saludos

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

Re: [Talk-es] historial ediciones

[andrzej zaborowski]

Hola Ricardo,

2013/1/1 Ricardo Sanz ricardosanz1...@gmail.com:
 Hola, desde hace aproximadamente un mes cuando le doy a la flechita de
 editar ya no me sale la última opción para ver quién ha editado una
 determinada zona. sabéis como puedo hacerlo?

Antes, hasta hace un par de meses, la opción de capa de datos estaba
en el mismo lugar donde eliges la capa de tiles, es decir en la
esquina derecha superior.  Temporalmente la movieron al botón de
editar y ahora la han vuelto a poner donde antes.

Saludos

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

Re: [Talk-us] MassGIS Building Import - process

[andrzej zaborowski]

On 15 December 2012 20:09, Jeff Meyer j...@gwhat.org wrote:
 Paul - I've added a few comments and questions about changeset size and
 revert policies on the Import Guidelines  Plan Outline wiki pages.

 Are there any recommended changeset size limits and/or revert plan
 practices?

One good practice is not to revert data that is not known to be wrong.
 If a big changeset fails halfway through it's possible to fix the
remaining part to use the nodes that have been uploaded and continue,
rather than delete the 1000s of nodes just to create new ones in the
same places.

You can probably now do that in JOSM by downloading the changeset
containing the orphaned nodes, opening in JOSM together with the data
being uploaded and telling the validator to fix all duplicate nodes.
 Myself I've been using the python scripts at
http://wiki.openstreetmap.org/wiki/Upload.py in such situations,
although the api is much more stable now than it was a couple years
ago.

The other good practice, but possibly not usable with JOSM alone, is
not to let the program upload the naked nodes in bulk and then the
buildings in bulk.  You can sort the elements in such a way that every
50k element changeset contains say 45k nodes and 5k ways.  The scripts
let you limit the number of elements in a chunk which the next chunk
depends on to the minimum (optimally 0), this way there's no risk of a
passer by spotting orphan nodes and deleting some causing you
conflicts in your next chunk.

Cheers

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

Re: [Talk-us] MassGIS Building Import - process

[andrzej zaborowski]

On 15 December 2012 22:45, Paul Norman penor...@mac.com wrote:
 From: andrzej zaborowski [mailto:balr...@gmail.com]
 Subject: Re: [Talk-us] MassGIS Building Import - process

 On 15 December 2012 20:09, Jeff Meyer j...@gwhat.org wrote:
  Paul - I've added a few comments and questions about changeset size
  and revert policies on the Import Guidelines  Plan Outline wiki
 pages.
 
  Are there any recommended changeset size limits and/or revert plan
  practices?

 One good practice is not to revert data that is not known to be wrong.
  If a big changeset fails halfway through it's possible to fix the
 remaining part to use the nodes that have been uploaded and continue,
 rather than delete the 1000s of nodes just to create new ones in the
 same places.

 You can probably now do that in JOSM by downloading the changeset
 containing the orphaned nodes, opening in JOSM together with the data
 being uploaded and telling the validator to fix all duplicate nodes.

 This hasn't come up for me on an import but I've tried it with normal
 mapping. I don't believe you can do a fix all on duplicate nodes and instead
 have to resolve them all individually

With a current JOSM it seems you can select all the errors and click
fix, or you can select the Other duplicate nodes category and
click fix, I just checked.  But JOSM will add each pair of merged
nodes as an individual operation in undo history.

I noticed it also merges the dupe nodes when you're merging two layers
rather than copy from one layer and paste onto another.



  Myself I've been using the python scripts at
 http://wiki.openstreetmap.org/wiki/Upload.py in such situations,
 although the api is much more stable now than it was a couple years ago.

 What's your workflow? Do changes in JOSM, save and then pass to the scripts?

Yes.  The osm2change script understands the JOSM format and produces
and .osc.  With the TIGER name expansion the bot produced .osc files
directly which were reviewed in a text editor.


 The other good practice, but possibly not usable with JOSM alone, is not
 to let the program upload the naked nodes in bulk and then the
 buildings in bulk.  You can sort the elements in such a way that every
 50k element changeset contains say 45k nodes and 5k ways.  The scripts
 let you limit the number of elements in a chunk which the next chunk
 depends on to the minimum (optimally 0), this way there's no risk of a
 passer by spotting orphan nodes and deleting some causing you conflicts
 in your next chunk.

 The best way to do this in JOSM alone is to only merge in 1-5k nodes+ways at
 a time, review them, then upload. This also avoids most of the problems
 above.

 I would only ever do a 50k object changeset in very limited circumstances
 where I am confident that it is safe to do so. Even then I'd try to keep it
 under 25k normally. For normal imports I'd suggest 10k as a soft limit.


Yes, good points.

Cheers

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

Re: [Talk-us] MassGIS Building Import - simplify

[andrzej zaborowski]

Hi,

On 14 December 2012 02:12, Jason Remillard remillard.ja...@gmail.com wrote:
 In my town, there are 5427 buildings. 43,628 nodes, or 8 nodes per
 structure. I did a 0.25 meter simplify on the entire town, and the node
 count went down to 41,809. We are looking at an excess of 5%. 0.25 meter may
 seem tight, but consider that source data was from 30cm and 15cm per pixel,
 and I am sure the algorithms used do some kind of sub pixel interpolation.
 Until I can figure out how to do the simplification from my scripts,
 ..

As I understand some processing is done in PostGIS already.  You could
add a ST_SimplifyPreserveTopology(the_geom, 0.25) at the end of the
process and it should have the same effect.

Cheers

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

Re: [OSM-talk] [Talk-us] Proposed Welcome Working Group meeting (was: Role of the Wiki)

[andrzej zaborowski]

Hi,

On 10 December 2012 22:59, Martijn van Exel m...@rtijn.org wrote:
 * What has been attempted before? Did it work? Why (not)?

I won't be in the meeting but there's a (small) dataset that could be
used for analyses of whether automated welcome messages work.  I'm not
planning to produce statistics myself but others can run the
statistics that they see useful.  We're sending automated welcome
messages to users who's first node edit is within Poland and some two
months ago after talking to Paul Norman I changed the logic to only
send the message to ~75% of those users so that the other ~25% could
be used for comparisons with a good probability that the receiving of
the message is independent from other factors.

Roughly all editing users with UIDs = 813385 and not divisible by 4
were greeted and those divisible by 4 were not (note that the order of
messages is based on the time of first edit, not on the UID).  The
sample is still small, we see about 4 new users a day on average.

I maintain a simple python api to send OSM messages[1] and if it is
decided that it would be good to start welcoming users in a different
region with a specific message I can add that fairly easily if the
rate of new users is below the rate of messages allowed by rails port.

Cheers

1. https://github.com/balrog-kun/osm-scripts

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

Re: [Talk-us] Proposed Welcome Working Group meeting (was: Role of the Wiki)

[andrzej zaborowski]

Hi,

On 10 December 2012 22:59, Martijn van Exel m...@rtijn.org wrote:
 * What has been attempted before? Did it work? Why (not)?

I won't be in the meeting but there's a (small) dataset that could be
used for analyses of whether automated welcome messages work.  I'm not
planning to produce statistics myself but others can run the
statistics that they see useful.  We're sending automated welcome
messages to users who's first node edit is within Poland and some two
months ago after talking to Paul Norman I changed the logic to only
send the message to ~75% of those users so that the other ~25% could
be used for comparisons with a good probability that the receiving of
the message is independent from other factors.

Roughly all editing users with UIDs = 813385 and not divisible by 4
were greeted and those divisible by 4 were not (note that the order of
messages is based on the time of first edit, not on the UID).  The
sample is still small, we see about 4 new users a day on average.

I maintain a simple python api to send OSM messages[1] and if it is
decided that it would be good to start welcoming users in a different
region with a specific message I can add that fairly easily if the
rate of new users is below the rate of messages allowed by rails port.

Cheers

1. https://github.com/balrog-kun/osm-scripts

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

Re: [Talk-us] MassGIS building conversion

[andrzej zaborowski]

On 11 December 2012 03:46, Jason Remillard remillard.ja...@gmail.com wrote:
 I think the plan should be to give the local mappers some time hand merge
 the data in, record what towns were done by hand, then import rest of the
 data with a script (or coarse not putting buildings over buildings).

Sounds like a reasonable plan.

 Most of
 the towns int he state don't have local mappers, most of the state will be
 done with the script.



 Re: license, I've heard personally from MassGIS director Christian Jacqz
 that all of Mass' GIS data is public domain based on the state's open policy
 on public records. I think this is fantastic, a link to a law or similar
 would still be useful.

 Is there address data that could be conflated with these buildings?


 Yes, there is a level 3 parcel data that has addresses in it. The buildings
 need to go in first, so we can do the addresses next year.

It might be better to include the addresses in the tags of the same
dataset so that the manually imported areas don't have to be worked on
twice, at least those addresses that can be associated with a
building.

It's a shame that the average height information was not included in
the attributes of those roofprints.  This information is often
estimated when people draw buildings manually by adding the floors
count, but actual heights for buildings in OSM more often comes from
imports.  
http://www.mass.gov/anf/research-and-tech/it-serv-and-support/application-serv/office-of-geographic-information-massgis/datalayers/structures.html
has an interesting description of how the heights were calculated for
MassGIS buildings in the areas covered by state LIDAR data for the
purpose of shifting the outlines to their correct places.  I wonder
how difficult it would be to repeat this process to add the height=
tags.

Cheers

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

Re: [Talk-us] [Imports] City of Seattle imports

[andrzej zaborowski]

Hi,

On 6 December 2012 14:04, Paul Norman penor...@mac.com wrote:
 Jeff Meyer @
 http://lists.osm.org/pipermail/imports/2012-December/001602.html
  How will you handle object conflation?
 Manually and methodically.

 Although not a trivial problem there is work underway on code that will
 handle the address-address conflation
 (https://github.com/pnorman/addressmerge).
 Address-POI and address-building conflation remains a purely manual job.

 It shouldn't be too hard to merge addresses with buildings they are within
 when the building has only one address within in and the building does
 not itself have an address. Addresses placed by building doors outside
 the building itself add complications but I expect they are solvable.
 Having said that it shouldn't be too hard, it's not trivial.

We've had a few localized address+building outlines imports.  I
haven't developed clean re-usable tools to do those tasks because the
datasets are so different every time, in scope, in data format,
accuracy, etc.  But usually I wrote simple python scripts for each
one, made of similar  re-usable blocks of code.  In the case of
address nodes placed roughly inside the buildings' outlines you can
re-use this scipt:
https://gist.github.com/4241509

Call it with two arguments:
./merge-building-addrs.py buildings.osm addresses.osm

It'll produce an output.osm file containing the same buildings and
addresses, but with the address tags assigned to the outlines where
there was exactly one address node contained within it.  Everywhere
else the nodes and the buildings remain intact.

In more complicated cases, e.g. nodes places near the entrances
slightly outside the building, as you mention, I found it's easiest to
load both datasets into two postgres tables and assign the addresses
using a postgis function like ST_DWithin() with a max. distance of a
couple of feet.

Similarly finding buildings that overlap with existing buildings in
osm can be easily done with ST_Intersects().  I'd usually add a
boolean column overlap containing true if the building collides
with an existing one.  Then in JOSM I'd skip those buildings with
overlap=true from upload and deal with each one manually.

Address nodes conflation is easier done in python because it requires
a little text processing.

Cheers

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

Re: [Talk-us] US Addressing

[andrzej zaborowski]

On 29 November 2012 21:12, Toby Murray toby.mur...@gmail.com wrote:
 Now for the hard part. Converting and conflating the information with
 the non-trivial number of addresses I have already collected on the
 ground.

Compared to conflating names or geometries, addresses are not a
problem because the street and the housenumber form a unique id.
Before comparing them it is worth splitting the street name into
words, reordering the words within the name to order them lexically,
and abbreviating them using a not-necessarily-perfect word list (such
as that from tiger or nominatim), to account for variations.  We've
had to do that for one city recently but it turned out to be a simple
check.

The (150 loc) conversion script for that data would read 4 files:
* the new addresses in a particular format,
* an output of an overpass/xapi query for elements tagged with
adds:housenumber=*
* an output of an overpass/xapi query for ways tagged with building=*
* an output of an overpass/xapi query for named highways.

it would output:
* an .osm file adding the addresses missing from OSM, either attached
to existing buildings or added as nodes
* a list of potentially missing streets who's names appeared in the addresses.

Cheers

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

Re: [Talk-us] street name expansion thoughts

[andrzej zaborowski]

On 27 November 2012 04:26, Toby Murray toby.mur...@gmail.com wrote:
 On Sun, Nov 25, 2012 at 7:34 PM, Clifford Snow cliff...@snowandsnow.us 
 wrote:
 I've been cleaning up are area of Jackson County, NC and found roads where
 the name expansion algorithm failed to expand all of the abbreviations . For
 example Yellow Bird Br Road.
 http://www.openstreetmap.org/?lat=35.36564lon=-83.24253zoom=17layers=M
 (not fixed yet)

 I didn't write down the problems thinking at first it was just an
 abnormality.

 I think it might be worth while to look at the names in the TIGER database
 for Jackson County NC to see why the names are not being expanded properly.
 I'll try to pull up a list tomorrow to see if it can help improve the
 expansion algorithm.

 I assume the Br is supposed to be Branch? It seems to just be an
 oddity in the TIGER data. The name field, where you would see Main
 for North Main Street has the value of Yellow Bird Br

 It might be because this road seems to have two type suffixes: Branch
 and Road. But the TIGER data model only allows for one so they shoved
 the first one into the name field. Ideally (IMO) they should have put
 Branch in its unabbreviated form into the name field. But I guess
 that would have been too easy. Have you found very many of these?

Another common example is Cemetery Road (Cem Rd) or XYZ Lake Road (Lk Rd).

For this reason the python expansion bot that run on the west US
allows multiple prefixes  suffixes regardless name_type tag, but this
required adding some special cases.

Cheers

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

Re: [Talk-us] TIGER expansion bot

[andrzej zaborowski]

On 27 November 2012 03:53, Serge Wroclawski emac...@gmail.com wrote:
 On Mon, Nov 26, 2012 at 9:50 PM, Clifford Snow cliff...@snowandsnow.us 
 wrote:
 I did look at your tiger.py script. I think br might also stand for branch
 as well as bridge. Also, I've seen mtn for Mountain.

 How would one determine whether a br would be bridge or branch? If we
 can't, then the script can't expand it.

In the TIGER docs br is only for branch, though there may be cases
that deviate from this.

Cheers

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

Re: [Talk-es] PN de Sierra Nevada

[andrzej zaborowski]

2012/11/21 José Juan Sánchez del Arco jj_sanchez_alme...@live.com:
 2012/11/20 José Juan Sánchez del Arco jj_sanchez_alme...@live.com:
  La página de la Junta de Andalucía tiene toda su información, incluída
  la de
  los mapas enCC BY-NC-SA 3.0. Supongo que esta información es igual que
  la
  del Ministerio de Medio Ambiente, ya que podemos ver exactamente la
  misma
  información que descargué. Lamentablemente no te puedo decir lo que hay
  de
  la página original, ya que por lo visto se ha caído y no me deja entrar.

 Una licencia NC podría ser problemática ya que OSM permite uso
 comercial y la parte SA se hizo incompatible en el momento de
 cambio de la licencia OSM. Creo que habría que enviar una pregunta.

 Lo que dices de los conflictos suena como un error de JOSM, lo
 intentaría con una versión mas antigua o mas nueva (si la hay), porque
 no debería pasar.

 Saludos

 ¿A quién hay que dirigir esa pregunta y qué hay que preguntar?

Me refería a preguntar a este parque natural, o al ministerio que
también publicó estos datos si te dejan usarlos en OSM.

Saludos

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

Re: [Talk-es] PN de Sierra Nevada

[andrzej zaborowski]

Hola,

2012/11/20 José Juan Sánchez del Arco jj_sanchez_alme...@live.com:
 La página de la Junta de Andalucía tiene toda su información, incluída la de
 los mapas enCC BY-NC-SA 3.0. Supongo que esta información es igual que la
 del Ministerio de Medio Ambiente, ya que podemos ver exactamente la misma
 información que descargué. Lamentablemente no te puedo decir lo que hay de
 la página original, ya que por lo visto se ha caído y no me deja entrar.

Una licencia NC podría ser problemática ya que OSM permite uso
comercial y la parte SA se hizo incompatible en el momento de
cambio de la licencia OSM.  Creo que habría que enviar una pregunta.

Lo que dices de los conflictos suena como un error de JOSM, lo
intentaría con una versión mas antigua o mas nueva (si la hay), porque
no debería pasar.

Saludos

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

Re: [OSM-talk] Data copied from Google Maps

[andrzej zaborowski]

On 6 November 2012 00:29, Toby Murray toby.mur...@gmail.com wrote:
 On Mon, Nov 5, 2012 at 5:12 PM, Pieren pier...@gmail.com wrote:
 On Mon, Nov 5, 2012 at 9:06 PM, Frederik Ramm frede...@remote.org wrote:
 Not as far as I know.

 Sad that OSMF is not taking five minutes to post the question to
 Google. Some contributors did it in the past.

 I don't think that a personal message to one individual mapper from someone,
 even if in a high position at Google, should be read as Google allowing
 every mapper to use their imagery.

 Most of third party sources agreements came from a high position from
 that particular source. If we should wait an official 50 pages
 contract document signed by 25 lawyers, approved and published by
 OSMF, then we should stop using Bing aerial imagery immediately.

 Furthermore, the terms of service contain other restrictions besides the one
 about bulk feeds, e.g. an attribution requirement.

 You probably noticed that the ToS is almost not about street view but
 mainly about GMaps and GEarth. Attribution and permission is required
 if you copy the photos or map data which is not what is discussed
 here.

 The terms of service are for using the google maps API. In order to
 view street view images, you must use the google maps API. It doesn't
 leave a lot of room for interpretation.

 https://developers.google.com/maps/terms

 10.1.1. General Restrictions. (a) No Access to Maps API(s) except
 through the Service. You must not access or use the Maps API(s) or any
 Content through any technology or means other than those provided in
 the Service

 So you the only way to access street view is through the API.

 10.1.3 Restrictions against Data Export or Copying. (a) No
 Unauthorized Copying, Modification, Creation of Derivative Works, or
 Display of the Content. You must not copy, translate, modify, or
 create a derivative work (including creating or contributing to a
 database) of [...]

 Note the or contributing to a database in there. That pretty much
 exactly describes OSM.

 And regardless of the technical legality which may be somewhat of a
 gray area, Google has an infinite number of lawyers compared to OSMF
 and would likely prevail in any action they felt worth bringing
 against us.

The same is true for Microsoft and Yahoo!, in the end it boils down to
something someone at those companies said in an email to someone else.

Cheers

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

Re: [OSM-talk] Data copied from Google Maps

[andrzej zaborowski]

On 4 November 2012 02:06, Paul Johnson ba...@ursamundi.org wrote:
 On Saturday, November 3, 2012, Ian Sergeant wrote:

 On 04/11/12 07:24, Paul Johnson wrote:


 Would it be acceptable to use Street View to aid your memory of local
 knowledge of the ground truth?  Something that's on the tip of your brain
 and you have actually been there, but can't remember what a specific sign
 said?


 Next time, write it down or take a photo.

 For now, either get written permission from Google that you can use
 Streetview to populate their main mapping competitor's database, or go and
 check, or wait for someone else to check.

 We have decided that we want to be whiter-than-white, and not tiptoe
 through a legal minefield.


 I understand that, but I mean as a memory aid for places you have actually
 been to.

Here's something that Ed Parsons said in an email about Google
StreetView usage in OSM:

 the relevant clause in the terms of service is..

 2(e) use the Products in a manner that gives you or any other person access 
 to mass downloads or bulk feeds of any Content, including but not limited to 
 numerical latitude or longitude coordinates, imagery, and visible map data;

 so checking the odd street names is OK.. but every street name I would 
 suggest would represent a bulk feed.

Cheers

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

Re: [OSM-talk] Data copied from Google Maps

[andrzej zaborowski]

On 4 November 2012 21:20, Christopher Woods (IWD)
chris...@infinitus.co.uk wrote:
 On 04/11/2012 16:48, Andrew MacKinnon wrote:

 In my opinion, copying from Google Street View is still a legally
 dubious thing to do. There is no formal licensing agreement with
 Google that I know of. It is perfectly fine to capture data by taking
 pictures yourself, but relying on Google Street View cars to take
 those pictures is legally dubious. Google Street View is often
 outdated anyway. Copying from Google Maps is clearly not allowed.

 I realize that we don't want to alienate users, but I think that OSM
 still needs to be strict about deleting contributions from legally
 dubious sources. Many new users simply don't realize that copying from
 Google is not allowed, and may have made many other contributions from
 legal sources (which will not be deleted). In other cases, users don't
 realize that there are sources that OSM is legitimately allowed to
 copy from - e.g. I have had to explain to users in Canada that copying
 road names from Google is not OK, but copying from Geobase and Canvec
 is perfectly acceptable.

 This is an interesting discussion about where to draw the line. To use one
 example: I could walk to the end of my street right now and look at the
 street sign; I could then do the same for all neighbouring roads in my
 locality. However, I could go to Google Street View and do the same thing.

 For simple pieces of factual data like that, obviously in the public domain
 before Google began to compile their own imagery, my gut feeling is that
 this is arguably OK to do in a pinch. Whilst not preferred, and 'trumpable'
 by another user submitting empirical observations, it's not a clear
 infringement of Google's cache of data as they never had exclusive access to
 the information prior to their own compilation efforts.

 You can obtain lists of street names from Royal Mail - heck, you can scrape
 them from PD mapping sources. The road network hasn't changed that
 dramatically in 100 years, save for trunk roads and infill in increasingly
 urban areas (IMO).

 However, 1:1 copying of complete topographical or road network information
 is far past the mark and also both a clear infringement of copyrighted
 materials and the licence under which access to said data is granted by the
 owner(s).

 If you copied Street View information wholesale, it's also a similarly clear
 infringement of licensed, copyrighted materials. Just the street names,
 however, isn't (on its own) a capital offence nor an obvious infringement of
 copyright.

It doesn't really matter whether the information is copyrightable.
You can only access this information through the Google website and to
use it you have to agree to the terms of use of that website,
including agreeing that you wouldn't systematically extract data from
it.

I agree incompatible data should be removed from OSM but it makes no
sense for a normal user to go around deleting it because they have no
way to remove the information from the odbl database, which includes
the history of edits.  This can be done by redacting that data and
the DWG currently has this ability.  Also, as the beginning of this
thread showed, a user is unlikely to know what licenses or agreements
there are between the source and the OSM contributor.

Cheer

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

Re: [OSM-legal-talk] [Talk-us] press from SOTM US

[andrzej zaborowski]

Hi,

On 23 October 2012 11:44, Frederik Ramm frede...@remote.org wrote:
 ...
 During the license change discussion, my position was often this: Instead of
 trying to codify everything in watertight legalese, let's just make the data
 PD and write a human-readable moral contract that lists things we *expect*
 users to do, but don't *enforce*. - Maybe the same can be done with
 geocoding; we could agree on making no legal request for opening up any
 geodata, but at the same time make it very clear that we would consider it
 shameful for someone to exploit this in order to build any kind of improved
 geocoding without sharing back.

A related question is whether any agreement like that can be made
within the Contributor Terms.  With the thread about the Public Domain
OSM subset when someone said that the PD declaration had no real
meaning I asked myself what made that declaration different from
other license grants (I'm still not sure).  But a license, according
to Wikipedia, is an agreement not to sue under some conditions.  An
agreement not to sue under some conditions is a license.  But the OSMF
is bound by the Contributor Terms to only grant a subset of the two
licenses listed in the CT, in their specific versions.  So can it make
a statement declaring that it would not sue under some conditions
(e.g. use of the results of geocoding) and keep publishing data from
current contributions?

It can probably state that it understands the ODbL 1.0 license to
allow users to do this and that under given conditions, or to not
*apply* under some conditions in some jurisdiction (for example in
USA).  But this could also be abused by declaring something that is in
contrast with what OSM contributors think, an extreme case being a
statement that says that ODbL is effectively invalid, or that ODbL =
PDDL.  That could perhaps be treated as an agreement not to sue, i.e.
license.  So what kind of clarifications (if any) can the OSMF make
about the licenses?

As has been noted in the Public Domain subset thread, the contributors
can make license statement that they like, but the OSMF can still
enforce the database rights.  So a statement by the contributors (e.g.
on OSM wiki) that is not confirmed by the OSMF is not very helpful to
the end user.

Cheers

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

Re: [OSM-talk] [OSM-talk-fr] Continued aggression against French contributors (cadastre integration)

[andrzej zaborowski]

On 19 October 2012 09:17, Simon Poole si...@poole.ch wrote:
 ..
 The UMP imports show nicely how broken at least object level source
 tagging is, a large number of objects have/were infected by source tags
 from UMP imports without actually being derived from such data requiring
 heuristics to determine if they could be kept or not.

I disagree, what you're seeing is a result of a redaction logic based
on individual OSM entity's history.  As Frederik wrote in an email
probably over two years ago, anything relying on the object Id
persistence is outright broken.  This is exactly what the bot logic
relied on and fixing it will require heuristics.

Tagging entire changesets is at least equally broken because it
infects the clean edits in the changeset, while objects who's Id
changes later may be wrongly detected as clean.  It's a bigger
tradeoff.

Cheers

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

Re: [OSM-talk] [OSM-talk-fr] Continued aggression against French contributors (cadastre integration)

[andrzej zaborowski]

On 18 October 2012 23:05, Frederik Ramm frede...@remote.org wrote:
 In a recent message, to talk-it
 (http://lists.openstreetmap.org/pipermail/talk-it/2012-September/030778.html),
 Paul writes

 We recognize that the line between an import and assisted mapping is not
 currently clearly defined; however all the cases I have seen recently
 clearly were on the import side of that line.

 So he calls it assisted mapping, I called it using a variety of legal
 third-party material in the mapping process, we could also call it a
 manually verified, small-scale import.

 These things are ok and while it is not currently written, DWG does not
 enforce separate accounts for them. If that is any help, we can try to sit
 down together and try to clarify the line between assisted mapping and
 import.

 There are many reasons why we want mass imports clearly separated from
 normal, human-contributed data. We got burnt by this in the license change
 in Poland, where we had to spend massive amounts of time sorting between
 good and bad changesets contributed by the same account.

This is off topic in this thread, but I'd like to set the record
straight.  Who do you refer to as we when you say you had to spend
any time sorting those changes?  The LWG and the rest of the
contributors to the license change have done nothing at all to
understand what data in Poland was compatible with the new license and
which of it wasn't.  You might have noticed (or not) that pretty much
every sentence in LWG minutes referring to this data has a factual
error of some sort, especially the ones quoting any numbers.  Really.
This was on such a scale that the day before the redaction started
(Tuseday morning) I was asking people on #osm-dev including LWG
members and the bot operator, if any of the decisions made by LWG to
that time had in fact been taken into account.  What I learnt was that
the final rules to be applied by the bot were such that over 50% of
the data to be redacted by the bot in Poland was in fact compatible
with ODbL, while at the same over 50% of the data incompatible with
ODbL would be left in the database.  Completely nothing had been done
to that time.

(And even then there was not much will to do anything right.  I was
told that if I wanted to provide drop-in code to fix the basic
problems, then I had about 12 hours to do so -- that was another
statement that made Michael's Collins' reasonable effort and due
diligence simply laughable.  On that same day, the operator of the
bot had literally said that it was not his task to read LWG's meeting
minutes and implement those plans.  A week later when it turned out
that a human mistake caused too many objects to be redacted (mind you
those objects have not been unredacted to this day -- a joke on the
automated edits guideline where you're supposed to have the tools to
undo anything you do), another community member had come to #osm-dev
to ask about this and was quoted an hourly rate for programming work
by one of the OSMF board members for repairing the destruction done to
that contributor's work)

So I'll appreciate it if you can avoid saying that you'd spent time
sorting through any changesets (or have you and that work was simply
not used?).  I had agreed to provide the whitelists and blacklists
needed for the bot to approximate what would be a license-based
redaction because I felt responsible to both the Polish OSM community
and the authors of the CC-By-SA data to be removed, for what the OSM
project does with those people's contributions.  I had quit the OSMF
to avoid the responsibility for their movements.  But at that time I
had already spend *weeks* of programming work trying to help the OSMF
destroy less by writing the equivalent of the redaction bot to go
through UMP edits history.  And because of that decision I have even
spent a couple hours this last weekend helping the OSMF do *more*
destruction to free geographic data in the OSM database, instead of
doing something productive.

Now coming back to the question of dedicated import accounts, I don't
see they make a lot of difference.  They're not a huge burden to the
importer, but they neither do solve any problem that the source
tagging doesn't solve better already.  If you want to redact the OSM
database ignoring basic facts and information that has been provided
to you clearly and repeatedly by different people then not much is
going to help you.  Still the UMP imports usually have required days
to weeks of manual work before each changeset uploaded because of the
data model differences and I think you could easily put them in the
assisted import category.  Which would mean that there's more manual
work in them than 3-rd party and using either a separate account, or
entire-changeset tagging, would cause more false negatives than not.
You could do that work in smaller changesets but you'd lose the
atomicity or bisectability in git speak, where you'd have a map
state in between the beginning of the work and the 

Re: [Talk-us] Abbreviating names in tools

[andrzej zaborowski]

On 6 October 2012 21:57, Werner Poppele popp...@hm.edu wrote:
 Hi Toby,

 there is a typo in line 262 of file shorten.c:

 Lhauptbanhof, Lhbf,

 must be

 Lhauptbahnhof, Lhbf,

Thanks, fixed.  Note that the German word list is just a stub and
needs input from a more knowledgeable person than me.

Cheers

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

Re: [Talk-es] visualizacon curiosa

[andrzej zaborowski]

2012/10/4 Simó Albert i Beltran s...@probeta.net:
 Creo que por desgracia no es un caso aislado:
 http://osm.org/go/xUcso7QWS--

 En su día me puse en contacto con el autor, que creo que esta en esta lista,
 proponiéndole que promoviera un tag para las lineas de tiza...

Hace varios dias pegue el link anterior en IRC y me han informado que
existe el tag marking=* y un renderizador que lo usa (no tengo manera
de verlo ahora).  Alguien mostro un lugar parecido en Alemania donde
las lineas se han marcado con el tag barrier=line, que tambien parece
incorrecto, pero menos incorrecto que barrier=fence, y que se ve en
mapnik ya que mapnik ignora el valor de la etiqueta barrier.

Saludos

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

Re: [Talk-es] visualizacon curiosa

[andrzej zaborowski]

2012/10/4 Jaume Figueras i Jové jaume.figue...@masafi.cat:
 Pintar las líneas de un campo? A mi me da información de que deporte se
 juega en el sin tener que ir a la ventana de información. Cuanta gente irá a
 la ventana de información para saber de que deporte es un campo? No creo que
 esto haga daño a nadie y puede ser útil a alguien. Ventajas, inconvenientes,
 cómo, cuando, por qué? Se puede discutir.

 Borrar la información? Pues el resultado es que ahora no sé si un campo es
 de fútbol o de hockey. La información se ha perdido y el mapa es más pobre.

Como ya han dicho los demas puedes usar el tag sport= para esto.  Aqui
tienes unas teselas de osm que lo visualizan con iconos:

http://a.osm.trail.pl/osmapa.pl/17/73213/43160.png

No digo que las lineas no tengan algun otro uso..

Saludos

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

Re: [Talk-es] Mercator-Peters

[andrzej zaborowski]

2012/9/25 Cruz Enrique Borges cruz.bor...@deusto.es:
 Básicamente lo que explicaba es que el mapa de Peters no es más que una
 modificación del Mercator para mejorar las áreas y que complica mucho
 los cálculos sin introducir ninguna mejora real (porque sigue siendo
 aproximado). De hecho hay alternativas mucho mejores para aproximar las
 áreas usando modificaciones de Mercator (creo que se llaman equiareales
 o no se que del seno, no me acuerdo) que desde un punto de vista
 geométrico son muy superiores, sin embargo no se usan porque Mercator
 a solas es muy simple y permite navegar por el mapa con facilidad
 (porque está DISEÑADO para ser así).

 El caso es que Peters fue un espabilado que le vendió la moto a la ONU
 y a las ONGs y les coló su mapa que básicamente sirve de cuadro, pero
 que para la práctica no funciona porque no tiene absolutamente ninguna
 de las propiedades que debe tener un mapa: ni puedes calcular caminos
 más cortos (geodésicas), ni puedes trazar rumbos (mercator), ni puedes
 calcular áreas (el que comentaba antes). Su única ventaja respecto a
 Mercator es que las áreas de ciertos continentes están mejor aproximadas
 que las de otros, pero a costa de PERDER la capacidad de trazar rumbos!

Que yo sepa (pero nunca he intentado analizarlo en detalles) la
proyeccion de Peters tiene las propiedades parecidas a las del
mercator popular.  O sea que no se perderia mucho.  La diferencia
tampoco es que Africa aparezca MEJOR representada, solamente que
aparece mas grande.  Basicamente en vez de agrandar las areas cuando
mas te alejes de la linea ecutatorial, se agrandan cuando mas te
acerques a la linea ecuatorial.

En fin todas las proyecciones tienen sus problemas.  La manera de
mostrar el mapa que para mi tiene menos problemas es la del globo,
tipo Marble y Google Earth.  Existen ya librerias javascript parecidas
a OpenLayers que usan WebGL para mostrar un globo tridimensional,
espero que en osm.org tambien en algun momento se empiecen a usar.

Saludos

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

Re: [OSM-talk] Import guidelines proposal update

[andrzej zaborowski]

On 20 September 2012 08:02, Greg Troxel g...@ir.bbn.com wrote:
 I'm mostly a lurker in these discussions, and generally more pro-import
 than many who participate in import decisions.  But I find the 'separate
 account for import' to be an utterly reasonable (along with the rest of
 the guidlines), easy to follow rule, and I am boggled by the objections
 to it.

I haven't followed all of this thread, but here's my experience with
this rule or recommendation.  First of all setting the username
through which you're uploading your edit is such a small issue that it
doesn't really matter for the person uploading. But then I don't see
it as solving any problem compared to source= tagging either on
objects being uploaded, or changeset (often the granularity provided
by tagging entire changesets is completely unpractical and would
result in more than 50% false positives).

Secondly I don't see it as an overwhelming trend currently in OSM.

Thirdly it introduces the problem of how many import accounts to use,
what to name them and potential anonymity of the person uploading the
changes if the account name doesn't contain their nickname.  In the
Spanish community there has been a strong will to follow all the
import guidelines when the Corine Land Cover dataset was being
discussed, analysed and prepared for importing.  The import guidelines
wiki page gave everyone the idea that it would be best to use a single
collective account with the same login details used by all the people
participating.  It's now obvious that this wasn't a good idea because
it was difficult to contact the person who did the actual work in case
there was a need for discussion, on top of that there's the practical
problem of sharing login details.  As with most imports there's days
or weeks (sometimes months) of manual processing that needs to be done
before data is ready for upload to OSM, and this is done by a real
person.  I think the whole point of having accounts in OSM is for the
people uploading their work to be easily contactable.

Fast forward two years and the current (lasting for about a year now)
Spanish cadastre discussions and import attempts have an even stronger
push to follow all the import guidelines because the DWG has blocked
these import attempts on various occasions (which from my point of
view is continuing to damage OSM in Spain because mappers are left in
a limbo -- there's no point drawing building outlines in their towns
from imagery if they have a better source at hand).  Well, this time a
single import account has been registered per province with a single
person coordinating the (potential) imports in each province.  The
assignments have been documented on the wiki.  This is better but the
account names are still not directly linked with real people, and the
division by provinces is artificial because the data was supposed to
be uploaded by users only for the areas they know personally, which
may be on village level for example.

Cheers

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

Re: [OSM-talk] Import guidelines proposal update

[andrzej zaborowski]

On 20 September 2012 00:41, Richard Fairhurst rich...@systemed.net wrote:
 Martin Koppenhoefer wrote:
 I believe that dedicated accounts are generally better for
 imports than using mixed ones which are also used for
 original data. This really helps a lot in sorting data
 according to its intellectual properties holders.

 Yes, absolutely.

 The really obvious example of this is the Polish UMP data, which was
 licensed CC-BY-SA and could not be kept post-licence change. If dedicated
 accounts had been used, removing this data would have been relatively easy;
 in reality, it has been (and continues to be) a nightmare. :(

I think this is a counter example as it is well known which data is
imported, and it is still a nightmare.  The imported data is marked in
a way that was standard for imports, and continues to be used for
local TIGER 2011 imports for example.

Cheers

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

Re: [Talk-es] ¿Hay algun bot que limpie la base de datos?

[andrzej zaborowski]

2012/9/9 Jaime Crespo jy...@jynus.com:
 Suele ejecutarse 1 o varios que hacen esta tarea, pero se
 deshabilitaron durante el cambio de licencia.

Que yo sepa estos nodos por ahora no se van a eliminar automáticamente
porque muestran donde hay cosas que corregír. Ademas se pueden
reconstruir geometrias de las vías a partir de ellos.

Saludos

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

Re: [Talk-es] Eliminados Parques Naturales Cordillera Cantábrica en OSM

[andrzej zaborowski]

Buenas,

2012/9/7 Óscar Zorrilla Alonso oscar_zorri...@hotmail.com:
 Pero haciendo zoom sobre alguno de ellos, he visto que han desaparecido
 completamente los siguientes:
 - Parque Nacional de los Picos de Europa
 - Parque Natural de Somiedo

 Por ello, me gustaría saber si alguien puede trazarlos o recuperarlos de
 nuevo.

El parque de Somiedo lo encontre y corregí los roles inner/outer, a
ver si dentro de algún tiempo vuelve a aparecer.  De paso he eliminado
los miembros inner de la relación correspondieres a los lagos que
están dentro del parque ya que son parte del parque.  Yo entiendo que
inner se usaría cuando los lagos fuesen excluidos del parque por
alguna razón.

El de los Picos de Europa no lo he encontrado.

Saludos

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

Re: [Talk-us] Announcing Remap-a-tron

[andrzej zaborowski]

On 1 September 2012 15:28, Mike N nice...@att.net wrote:
 On 8/31/2012 11:17 PM, Martijn van Exel wrote:

 I want to add The Remap-A-Tron to the ever growing list of tools
 designed to support the ongoing remapping effort.


   That's a fantastic application!

Isn't this because it directly uses the data that OSM is not supposed
to use?  I guess it's less of a problem with roads in the continental
US, but elsewhere, when a user is pointed at a possibly blank spot on
a map with no imagery available, you can only expect them to attempt
to copy what they saw in the application.

Cheers

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

Re: [Talk-us] Discardable TIGER tags

[andrzej zaborowski]

On 29 July 2012 23:21, Toby Murray toby.mur...@gmail.com wrote:
 On Sun, Jul 29, 2012 at 3:25 PM, Ian Dees ian.d...@gmail.com wrote:

  While we're incrementing every single version number of TIGER data, we
 should think about expanding the road names, too. Using the prefix and
 suffix data already on the majority of the ways makes this pretty
 fool-proof, so where it makes sense I think we should do that, too.

 Please check your glasses and re-read my message :) I am absolutely
 not proposing an automated edit.

 I have a working JOSM that automatically deletes tiger:upload_uuid.
 The way I implemented it mirrors JOSM's concept of uninteresting
 tags. This means that there is a default list of discardable tag
 keys. The list can be modified in the advanced preferences. Search for
 tags.uninteresting in the preferences if you want to see how it
 works now.

 The question is just what goes in the default list that gets populated
 the first time you fire up a new JOSM version with this feature.

 So far I have:

 tiger:upload_uuid - definite yes

 tiger:source - No opinions

 tiger:separated - mixed feelings. If I could just remove no values
 there seems to be unanimous support but that would require doing it
 differently, probably hardcoding it in the source instead of going off
 of a user preference.

Or extending this user preference's syntax, probably not much work.


 tiger:tlid - there seems to be support for removing it although I do
 recall someone opposing it strongly in the past as Anthony mentioned.
 In theory it lets you link back to a specific TIGER object. In
 practice it seems minimally useful with way splitting/merging and a
 fairly high degree of certainty that an automated TIGER 2011+ reimport
 where this could actually be used is probably not going to happen.

I have opposed removing tiger:tlid in the past but this tag is
unlikely to be ever used in practice.  This information could also be
gathered from the history dumps even in case of way splits, they're
easy to detect. (For people interested in dbpedia and linked data it's
probably nice to see a direct external key of another database in a
database but it's apparent that this data is not being maintained)

Cheers

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

Re: [OSM-talk] OT - Unusual Bing imagery

[andrzej zaborowski]

On 24 July 2012 00:52, Hendrik Oesterlin hendrikmail2...@yahoo.de wrote:
 http://greenvilleopenmap.info/Airplane.jpg

 If you give the location of this image, it would be possible to look
 for its shadow and calculate an approximate altitude.

 The Bing imagerie could be satellite imagerie, not necessarily air
 plane imagerie.

The area in the screenshot seems to have a higher resolution than
satellites can achieve.  Also I've stumbled on big airliners in Yahoo
or Bing satellite imagery before and they look much different (longer
exposition time and the RGB components somehow have an offset because
of the altitude difference, like here:
http://www.streetviewfun.com/2010/airplane-on-satellite-image-2/)

Cheers

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

Re: [OSM-talk] OT - Unusual Bing imagery

[andrzej zaborowski]

On 24 July 2012 03:48, Alan Mintz alan_mintz+...@earthlink.net wrote:
 At 2012-07-23 16:02, andrzej zaborowski wrote:
 The area in the screenshot seems to have a higher resolution than
 satellites can achieve.


 Is this documented somewhere? Assuming from the look and ratio of
 measurements of the jet that it is a B737, the pic is at z20 (~12cm/pel @
 middle lats). I was under the impression that all of the Bing/Yahoo/Google
 imagery was still satellite-based, down to z21 (6cm/pel). I know Google has
 spots of UHR imagery at z22, but it seems they were still referred to as
 satellite. I've seen individual county websites with very nice imagery
 described as flyover, as though coming from airplane/helicopter,
 apparently on a contract basis.

I've assumed 0.5m/px is the technical limit for satellite imaging,
Wikipedia seems to confirm this more or less:
The latest commercial satellite (GeoEye 1) has a GSD of 0.41 m
(effectively 0.5 m due to United States Government restrictions on
civilian imaging).[1] I guess military satellites might have better
parameters, but anything you're likely to see on the web with a higher
resolution will be taken from within the troposphere.

I've been told once that 0.5m is the usual limit around the world
except Israel of which you're unlikely to see imagery better than 2m
due to the government's threats.

Cheers

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

Re: [OSM-talk] Very not happy

[andrzej zaborowski]

Peter,

On 22 July 2012 09:27, Peter Wendorff wendo...@uni-paderborn.de wrote:
 Am 22.07.2012 00:42, schrieb andrzej zaborowski:
 If you're asking me (not Maetma 91), I think the problem has been
 known since the early days of OSMI license view (easily fixable too).
 For example this city I believe was showing as clean although it was a
 while since I have looked at that layer: http://osm.org/go/0MtRfiBy-

 Here's a before/after the bot run comparison someone made for that
 city: http://postimage.org/image/sv7gh0rkp/
 http://postimage.org/image/8m60yvx8j/

 First of all that's not the ID(s) Frederik asked for.
 Secondly: if it has been known to you - did you provide a patch or at least
 a patch idea for it?

Wow, I wonder how people manage to ignore so many facts.  First of
all, I have not been silent about it, quite the opposite and the issue
must have been known to Frederik because I remember he participated in
one of the mailing list threads about it in mid 2011.

Secondly no one could provide such a patch because no one knows what
the bot is going to remove and what the LWG will deem clean or dirty,
the real discussions about what will the bot do started on the
rebuild list just a couple of months ago.  So are you even serious
about the patch suggestion?

In this particular case I have been discussing this issue with Simon
Poole of the LWG on IRC the day before the but ran (Tuesday last week)
and in the morning he decided that the objects would stay and
apparently later the same day changed his mind (I hope I'm not
misrepresenting what happened, if I am, sorry).

 If it has been known before that there has been an error, then you cannot
 complain about it suddenly being deleted against the OSMI view - because
 obviously you knew about that already.

Oh my, please re-read the conversation.  I haven't been complaining, I
was not a user of OSMI.  I simply pointed out a gross error in
somebody's statement.  Someone said something that was incorrect and
very ironic in face of how much people's hard work has been removed,
all I said is that this was incorrect.

Cheers

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

Re: [OSM-talk] Very not happy

[andrzej zaborowski]

On 21 July 2012 15:07, Frederik Ramm frede...@remote.org wrote:
 That's quite incorrect, millions of objects that were not flagged in
 those tools have been removed,

 Can both of you give us the object IDs of a couple of these objects to
 investigate?

If you're asking me (not Maetma 91), I think the problem has been
known since the early days of OSMI license view (easily fixable too).
For example this city I believe was showing as clean although it was a
while since I have looked at that layer: http://osm.org/go/0MtRfiBy-

Here's a before/after the bot run comparison someone made for that
city: http://postimage.org/image/sv7gh0rkp/
http://postimage.org/image/8m60yvx8j/

Cheers

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

Re: [OSM-talk] Very not happy

[andrzej zaborowski]

On 21 July 2012 00:55, Lester Caine les...@lsces.co.uk wrote:
 Maetma 91 wrote:

 I do that.
 JOSM plugin say no problem
 and now you break everything

 The licence check tools would have been showing problems. Nothing has been
 removed that was not flagged in those tools.

That's quite incorrect, millions of objects that were not flagged in
those tools have been removed, while millions of others that showed
red (that's not an exaggeration, I don't know how many but it's over
three millions that I know of) were in fact ODbL-clean and may end up
not being removed.

Cheers

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

Re: [Talk-es] Noticias OSM

[andrzej zaborowski]

2012/7/12 Iván Sánchez Ortega i...@sanchezortega.es:
 Y se pone en marcha el bot de edición de la ODbL:

 http://lists.openstreetmap.org/pipermail/imports/2012-July/001441.html

Por lo visto hoy termino de procesar España continental.  Con la
excepción de un par de cuadriculas creo que ya no van a desaparecer
datos de la bdd.

Saludos

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

Re: [Talk-es] descargar de limites administrativos.

[andrzej zaborowski]

2012/7/3 Jaime Crespo jy...@jynus.com:
 El 3 de julio de 2012 09:46, Wladimir Szczerban bolo...@gmail.com escribió:

 Hola todos,

 He estado hablando con la gente de OSM de Venezuela y nos interesa corregir 
 los limites administrativos. El principal problema es que no forman parte de 
 relaciones y que existen mucho límites duplicados.

 Me he mirado el articulo de Ivan 
 http://ivan.sanchezortega.es/fronteras_osm.html y he probado la opción de 
 los filtros, con esto he corregido algunos limites de municipios pero si 
 quiero bajar de admin_level a estado el área es muy grande y no me deja 
 descargar los datos en el JSOM.

 Como podría hacer para descargar los datos de los límites administrativos? 
 He probado descargarme los datos de Cloudmade
 http://downloads.cloudmade.com/americas/south_america/venezuela#downloads_breadcrumbs
  el venezuela.administrative.osm.bz2 y junto con el 
 venezuela.coastline.osm.bz2  pero a la hora de subir las modificaciones me 
 dan mucho conflictos que según los resuelvo me aparecen otros, y de esta 
 forma no he podido hacer mucho.

 Para cosas tan grandes, yo tiraría de planet.osm.org, me bajaría todo
 el mundo (o un extracto) y luego filtraría con osmosis. Así tendrías
 algo muy actualizado y con los números de versión, que es
 probablemente lo que te cause conflicto.

Normalmente si, pero desde abril en planet.osm.org no se publican los
planetas automaticos semanales.  Asi que download.geofabrik.de
contiene ahora datos mucho mas actuales, se actualizan cada dia.

Overpass en cambio actualiza los datos en vivo y es suficientemente
actual para que se use en JOSM en vez de descargar directamente de los
servidores de OSM.  (en realidad se actualiza cada minuto, pero es
suficiente)

Con ediciones basadas en extractos de Xapi / Overpass hechos con
filtración por tags hay que tener cuidado porque siempre son datos
incompletos.  Por ejemplo si te descargas los limites administrativos
existentes con sus ways y nodos, los mismos nodos a veces forman parte
de carreteras que no se han descargado, por lo cual si borras el nodo
te va a dar un conflicto al subir.  Si lo que haces es solamente crear
y modificar objetos no habrá este riesgo.

Cloudmade suele ser el mas desactualizado, en realidad no se si
todavía lo están manteniendo.

Al final puede ser que te de conflictos aunque uses los datos mas
actuales porque ya sabéis que se están editando todo el tiempo.  Para
evitarlo se puede intentar hacer los cambios rápidamente y por la
madrugada.  También se puede dividir el área en partes mas pequeñas si
es grande.

Saludo

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

Re: [Talk-es] descargar de limites administrativos.

[andrzej zaborowski]

2012/7/3 andrzej zaborowski balr...@gmail.com:
 Normalmente si, pero desde abril en planet.osm.org no se publican los
 planetas automaticos semanales.  Asi que download.geofabrik.de
 contiene ahora datos mucho mas actuales, se actualizan cada dia.


Me dio por verificar si geofabrik tiene extractos para Venezuela y
resulta que no los tiene.  Habría que pedir al dueño de geofabrik
(frede...@remote.org) que los habilite.

Saludos

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

Re: [Talk-us] Seeing things you don't care about in the database

[andrzej zaborowski]

 On Mon, Jun 11, 2012 at 4:47 PM, Nathan Edgars II nerou...@gmail.com
 wrote:
 I agree with this. But I'm not sure that there is a solution. You can use
 XAPI/Overpass API to download only roads in an area, but you get conflicts
 (or worse, you move a node and screw up something else without realizing it)
 when nodes are shared with other non-downloaded features. This can happen
 directly (road passing through a building or the IMO bad practice of using
 roads as landuse borders) or indirectly (e.g. road - parking lot - building
 - landuse).

One option would be for every object returned from an API query to
have a complete/incomplete flag.  This flag would be set if an object
(e.g. a node) is part of another object that has not been downloaded
because it's not on the same layer.  If the editor sees such an
object being modified, it pulls all the parent elements from the
API.

Cheers

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

Re: [Talk-us] Special issues in LA remap

[andrzej zaborowski]

On 6 June 2012 09:07, Steve All steve...@softworkers.com wrote:
  andrzej replied:
  Is it a pressing issue though?  Mike N already said this, but the
  license redaction algorithm is being designed to do no more damage
  than a revert of the tainted edits, with the exception of undeletions
  mentioned by NE2.  So, by my understanding, the best you can get by
  reverting edits is a state similar to that which you'll obtain by
  doing nothing and moving on to actual useful mapping.


 SteveA here:  Then I think what might make most sense is to point Charlotte,
 me, and other readers of this list to Mike N's license redaction algorithm
 thread.  I guess I missed that.

I was referring to the post at the beginning of this thread.  You're
right that the redaction algorithm is being created at this time so
it's hard to know what it's going to look like.  However it's quite
clear that a plain revert of all tainted edits would produce a
(mostly) clean dataset and I believe that is the baseline assumption
for the redaction algorithm.  From there all the work happening is
done to minimize the damage, make it better than a plain automatic
revert if possible.

So all I'm saying is that a plain revert of the edits is not going to
produce better results than just doing nothing, because the redaction
algorithm is likely to do a job that's at least as good.  On top of
that the definition of what is tainted is still changing (there are
places where the current definition as written on the wiki gives an
almost opposite effect to what is intended -- incompatible data would
be preserved and compatible data removed).

Replacing data with TIGER 2011 roads might be a better idea but it's
orthogonal to the license change, it can be done before as well as
after the change.

Cheers

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

Re: [OSM-talk] Changing capitalization (Lima)

[andrzej zaborowski]

On 31 May 2012 17:39, Alex Barth a...@mapbox.com wrote:
 We're currently working with Ruben (user Rub21) on fixing street name 
 capitalization in Lima - a lot of the street names are ALL CAPS where they 
 should be properly capitalized. We're doing this work manually right now and 
 are well under way. It's quite time intensive though - any examples of where 
 such a cleanup process has been automated on OSM before?


I ran such a process on the POI names in Girona that were imported
just before the SOTM'10.  Accents were correct already and python
dealt with them correctly.  The only special cases were some
prepositions that are written in lower case and the Catalan use of
apostrophe.

http://www.openstreetmap.org/browse/changeset/5073672 is one of the changesets.

Cheers

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

Re: [OSM-talk] OSM : It's a shame !!!

[andrzej zaborowski]

On 29 May 2012 11:28, Thomas Davie tom.da...@gmail.com wrote:
 On 29 May 2012, at 10:27, Floris Looijesteijn wrote:

 That's some great imagery if he can read the name signs on that street...

 The fact that all the tags were ODbL safe had already been established – they 
 were created by another user who had accepted.

Acceptance of the Contributor Terms does *not* imply ODbL safety.

Cheers

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

Re: [OSM-talk] OSM : It's a shame !!!

[andrzej zaborowski]

On 29 May 2012 11:01, Thomas Davie tom.da...@gmail.com wrote:
 If I remember correctly (someone correct me if I don't), a lawyer has agreed 
 that it's okay to keep node positions and ways where a user would reasonably 
 have created the same way from an ODbL compatible data source.

I don't know if a lawyer has said that, but I think it's unlikely to
apply to tracing from imagery, first because the node positions are so
unlikely to match if recreated from imagery, and secondly because
Potlatch, I think, now has a whole mode designed to get rid of
original node positions and add new ones quickly.  (It's still a huge
simplification with many open questions -- what about the
directionality of ways where the direction is not significant, i.e. no
oneway=yes tag -- this information could constitute a protected
database on its own but all the remapping methods retain such
information.)

Cheers

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

Re: [OSM-legal-talk] [OSM-talk] [Osmf-talk] OSM : It's a shame !!!

[andrzej zaborowski]

On 28 May 2012 23:03, Mike  Dupont jamesmikedup...@googlemail.com wrote:
 moving the discussion to legal

 On Mon, May 28, 2012 at 8:02 PM, andrzej zaborowski balr...@gmail.com wrote:
 Copying and pasting is not a copyright infringement.  The Contributor
 Terms don't require that the data inserted into the database be
 compatible with ODbL -- only the current licensing terms, which still
 means CC-By-SA.  Otherwise many many normal edits would also
 constitute an infringement.

 CC-BY-SA requires attribution.

 '' You must keep intact all copyright notices for the Work and give
 the Original Author credit reasonable to the medium or means You are
 utilizing by conveying the name (or pseudonym if applicable) of the
 Original Author if supplied; the title of the Work if supplied;''
 http://creativecommons.org/licenses/by-sa/2.0/legalcode

 and
 This License and the rights granted hereunder will terminate
 automatically upon any breach by You of the terms of this License

 so the new uploader lost his rights to copy it if he did not attribute it.
 So it is an infringement, unless you take the view that this data is
 not copyrightable at all and the cc-by-sa license does not protect
 anything.

Mike, I wouldn't say the usernames appearing in the object history on
www.osm.org/browse/... are used to fulfill the attribution
requirement.  First of all it'd break for many different basic
operations done in the editors such as splitting and merging ways,
copying tags, placing POIs with spatial reference to nearby streets.
I kind of agree with Frederik Ramm's statement that (from memory)
anything that relies on object id persistence is broken and so is
part of the current redaction algorithm.

I think a reasonable expectation for a contributor to have is that
they'll be attributed as shown in the osm.org/copyright page, i.e.
collectively as OpenStreetMap contributors.

Cheers

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

Re: [OSM-talk] [Osmf-talk] OSM : It's a shame !!!

[andrzej zaborowski]

On 28 May 2012 21:42, ce-test, qualified testing bv - Gert Gremmen
g.grem...@cetest.nl wrote:
...
 Why is there no tool for checking on copy paste copyright infringement…

Copying and pasting is not a copyright infringement.  The Contributor
Terms don't require that the data inserted into the database be
compatible with ODbL -- only the current licensing terms, which still
means CC-By-SA.  Otherwise many many normal edits would also
constitute an infringement.

The infringement will occur if the OSM Foundation decides to publish
the database under the ODbL based on the CT-acceptance.

The problem has been discussed many times on the legal-talk@ list,
most of the times with the same conclusion, including opinions by a
copyright lawyer.  The LWG hasn't reacted as far as I've seen.
Neither has any recent part of the license change process been legally
reviewed, as far as I know again.

Cheers

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

Re: [OSM-talk] Import of buildings in Chicago

[andrzej zaborowski]

On 27 May 2012 18:11, Colin Smale colin.sm...@xs4all.nl wrote:
 On 27/05/2012 17:54, Worst Fixer wrote:

 Hello.

 There is on going import of Buildings in city Chicago.

 Import is held by following account:
 http://www.openstreetmap.org/user/chicago-buildings

 I found no discussions of this import. No announcement. I searched bad?

 It is absent from following web page:
 http://wiki.openstreetmap.org/wiki/Import/Catalogue

 I want know why importer uses following tags:

 * chicago:building_id (314 330 objects, used by 2 users).

 I sent letter to importer, and he said he will not import this tag any
 more. But, he continues to. No justification of need for tag was given.

 Who has the right to ban a tag? Where does it say that a tag has to be
 justified?

The DWG has the right to block imports with unjustified tags and has
done that on many occasions, and also made it clear on the imports@
list that this would happen.  It's also documented on the wiki.

However the partial street name tags have been discussed on talk-us@
several times and were considered to be useful.  I'd also say that a
single id tag referring to another database may be useful and not an
overkill to the OSM database.  Not saying that the precise tagging
shouldn't have been discussed beforehand.

Cheers

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

Re: [Talk-us] Road Expansions and Seattle Imports (if you're the Seattle importer, please read!)

[andrzej zaborowski]

On 19 May 2012 21:02, Serge Wroclawski emac...@gmail.com wrote:
 On Sat, May 19, 2012 at 1:31 PM, Mike N nice...@att.net wrote:
 On 5/19/2012 12:52 PM, Serge Wroclawski wrote:


  Ultimately, the only way to get a 100% successful upload is to query the
 changeset on failure to determine what was actually uploaded, then resume
 from that point.

 While true, that method in isolatiuon is a bit complex and should be
 unnecessary.

 The OSC upload method is transactional in nature. If you get a
 positive response from it, you can know the upload succeeded. The
 issue is that there can be a network interruption between the upload
 completion and the return response. During that time the transaction
 has completed successfully but the client won't know.

 If there is a 1:1 correlation between OSC and changeset, that's fine,
 but generally uploads are often done with large chagesets.

 There are a few ways to handle this (including async upload methods in
 the API code, which has been proposed), but right now, AFAIK, there's
 no public code for making reliable mass uploads to OSM.

As mentioned on irc, I trust the tool set I did the original TIGER
expansion with.  I've used it for many other uploads too and I never
had to revert a single upload, i.e. it was always possible to resume
the process in case of a network error or conflict.  I've heard of two
or three more people who used it successfully.  It also (tries to)
solve the problem of nodes being uploaded in bulk before ways get
uploaded, before relations, so this minimizes the probability of
someone spotting orphan nodes in the middle of an import and removing
them.

Unfortunately it's not very user friendly and requires manual
intervention sometimes.  I'd try improving it instead of starting from
the beginning though.

It's documented here: http://wiki.openstreetmap.org/wiki/Upload.py

It is also limited to xml files that fit in memory because it uses the
python ElementTree parser right now.

Cheers

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

Re: [OSM-talk] Worst of OSM

[andrzej zaborowski]

On 15 May 2012 15:37, Pieren pier...@gmail.com wrote:
 On Tue, May 15, 2012 at 2:53 PM, Kate Chapman k...@maploser.com wrote:
 Personally I think it is discouraging. I think positive encouragement
 is much better than this negative method.

 The problem is that this page is mixing real mistakes (mainly bad
 imports) and areas where the geodata do not comply with the author
 priorities or what the author thinks about what should be mapped first
 (mainly good imports). He is probably restrained by his personal
 experience where mapping must start with major roads, places names
 then minor roads, all with GPS and then, landuse, buildings,
 addresses, etc with hires aerial imagery, all surveyed by an army of
 local enthusiasts.

The site seems to mostly make fun of the current resulting state of
the map, rather than the process that led to that state.  I'd compare
it to http://googlemapsfail.tumblr.com/ rather than argue whether it
is useful to OSM or not.  If it hadn't been created now, someone else
would create one at some later point.

Maybe the fact that it's German (assuming that it is) is a sign of
OSM's popularity there, and approaching Google Maps.

Cheers

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

Re: [Talk-us] Fixing TIGER street name abbreviations

[andrzej zaborowski]

On 11 May 2012 22:17, Dale Puch dale.p...@gmail.com wrote:
 I understand the script checks for only one instance of the abbreviation.
 My point was what is someone manually expanded ONE of the abbreviations,
 leaving st something street?  Is that checked for?  The question also
 applies to Dr something Dr previously changed to Dr something Drive, and
 possibly directionals as well.  Serge seems to be doing a good job with
 this, and this is just feedback so there aren't any incorrect expansions.

The way the old script deals with those, is it has a list of
abbreviations that come as a suffix and those that come as a prefix,
from the TIGER documentation.  It checks suffixes starting from the
end, so if you have St something St E or St something St East,
it'll only check E or East and then St and then stop because
something is not a known suffix.

There are cases where something can be both a suffix and a prefix, but
those cases are known from the TIGER documentation.

Note that that St something St, can be Saint something St, but it
can also be State something St.  The script uses a list of things
that can be saint and those that can be state owned.

Cheers

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

Re: [Talk-us] First bona fide mini-roundabout spotted

[andrzej zaborowski]

On 7 May 2012 22:28, Nathan Mills nat...@nwacg.net wrote:
 So this is not/should not be a mini_roundabout? It seems a little silly to
 call it anything else, since the city just dug a hole in the center of the
 existing intersection, built a circular curb, and planted a tree:

 http://g.co/maps/e2gsv

 What about this one? Also a full on roundabout?

 http://g.co/maps/d6n74

These two don't give priority to the vehicles going round so they're
not roundabouts going by the wiki definition.

This is one in Berkeley that I have previously tagged mini_roundabout:
http://g.co/maps/5uc9t (using the size criteria) but from Google it
looks like there are stop signs only from Mathews St even though there
are roundabout symbols on the island.  So should this be redrawn as a
circle, with highway=stop nodes from N/S only?

Cheers

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

Re: [Talk-us] Excellent progress, u.s.

[andrzej zaborowski]

On 14 April 2012 03:30, John F. Eldredge j...@jfeldredge.com wrote:
 One drawback to this new-coordinate technique is that, in some cases, the 
 tainted nodes will have been in the proper locations to match the real world. 
  So, in order to make the cleanup bot not consider the nodes to be tainted, 
 we have to knowingly make the map data less accurate than it had formerly 
 been.


It also will remain tainted, only the bot will not know about it and
consider it untainted.  So it's a way to trick the bot and potentially
put the OSM Foundation under legal risk.

This is why the remapping effort before the bot run is finished, is a
Really Bad Idea.  It is both more time costly and it is provoking
users to cause incompatible IP to be preserved over the license
change, often unconsciously.  See all the ideas of using the
incompatible IP to create the new compatible IP, such as using the
tainted coastlines data to remap small islands.  (RichardF said he
does not agree it's a bad idea, but he wouldn't explain which point he
disagrees with or why)

Cheers

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

Re: [OSM-talk] Proposed mechanical edit: Empty Relations

[andrzej zaborowski]

On 13 April 2012 11:12, Paul Norman penor...@mac.com wrote:
 Through editor errors or other mistakes there are a number of relations in
 OSM which have no members. I propose a mechanical edit to delete these where
 they are not members of some other way. My proposed procedure, documented at
 http://wiki.openstreetmap.org/wiki/Mechanical_Edits/pnorman_imports is to
 identify these with my pgsnapshot database and delete them if they aren't
 referenced by any other relation.

 If they are referenced by another relation I will investigate them and deal
 with them manually.

 I've investigated a few of them and they appear to be caused by people
 deleting ways from multipolygons but not deleting the relation. I don't want
 to investigate all 5200 by hand so I'm proposing the mechanical edit.

 I will filter out ones touched in the last 24 hours to avoid conflicting
 with anyone.

This thread comes up every some time
(http://lists.openstreetmap.org/pipermail/dev/2009-August/016658.html,
http://lists.openstreetmap.org/pipermail/talk/2010-November/055075.html).
 In 2009 I ran a very similar operation with 4.5k relations deleted as
discussed in the first thread I linked.  The lesson from it was that
some relations are referenced from outside of the database, mainly
from the OSM wiki.  Those should not be deleted automatically either
or it'll upset some users.

Cheers

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

Re: [OSM-talk] Komuna e Malishevës, Serbia ?

[andrzej zaborowski]

2012/4/4 kmilos kmi...@gmail.com:
 The fact that you you sign off as and support the 'Free Libre Open Source
 Software KosovA' discredits you from any meaningful discussion, and any
 claims of the good-willed intentions of an organization bearing such a name.

The fact that you look at who makes a claim before considering the
arguments they have demonstrated the claim to be true with discredits
you from any discussion at all I guess.

The on the ground rule really is the best, and generally agreed way
in this project, to avoid political decisions and avoid having a
database of unverifiable information.  It's the same way linguists
define natural languages -- a language is what its users use, no
national or international body has the power to overrule that.

Cheers

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

Re: [OSM-talk] No Data overlay on OpenStreetmap.org

[andrzej zaborowski]

On 2 April 2012 09:40, Steve Doerr doerr.step...@gmail.com wrote:
 On 01/04/2012 21:30, Shaun McDonald wrote:

 It has been moved to the edit tab under the name Browse Map Data.


 Not currently working for me. I get

 Error in loading GML file
 /api/0.6/map?bbox=0.34649,51.421383,0.351724,51.423823



 then click OK. There's now a link on the left that says 'Retrieve this area
 from the API' but when I click on that I get

 Internal Server Error

That's because of the server maintenance.  There's a problem though
with re-opening the data pane once it's been closed.  I have to reload
the website to reopen it every time, otherwise it causes a

'null' is not an object @ openstreetmap-hash.js:128

(Safari)

+1 for putting it back in the layer switcher.

Cheers

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

Re: [OSM-talk] No Data overlay on OpenStreetmap.org

[andrzej zaborowski]

On 2 April 2012 16:50, Kai Krueger kakrue...@gmail.com wrote:

 andrzej zaborowski wrote

 There's a problem though
 with re-opening the data pane once it's been closed.  I have to reload
 the website to reopen it every time

 That should be fixed already. Are you still seeing this?

Seems to be Ok now, but I could reproduce the problem in the morning.
Thanks for fixing and sorry I couldn't send a fix.

Cheers

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

Re: [OSM-legal-talk] Digitizing from Balloon Maps

[andrzej zaborowski]

Hi,

On 10 March 2012 03:51, Kate Chapman k...@maploser.com wrote:
 Hey All,

 I was wondering what the license implications would be from digitizing
 from balloon maps that had been rectified from other satellite
 imagery.

 - So let's say you fly photos of an area
 - To stitch them together you use Google Maps imagery as the base
 - What is the deal with the imagery at that point?
 - If I trace the imagery is that really derived from Google Maps?

 It seems insignificant to me, but I wanted to get some insight.

I would also like to know, especially in the context of Jeff Warren's
mail on talk.  I think the legal side here is easier than the
community customs.  I have heard both obviously if it's rectified
using Google, it can't be used in OSM, and obviously it doesn't
matter.

I think Bing support in Map Knitter (even though legally it's in the
same bandwagon as Google) would have a better community acceptance.
Where I tried rectifying something with Map Knitter, Google imagery
was useless because of complete cloud cover, too.

Cheers

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

Re: [OSM-talk] iPhoto for iOS Not Using Google Maps

[andrzej zaborowski]

2012/3/9 Jaakko Helleranta.com jaa...@helleranta.com:
 Jaime wrote: My guess is that, at least in my area, they are mixing OSM 
 geometries and names with -very poor- labels from other source.

 ... Which would mean that (mixing and matching data in an area) they should 
 be contributing back to OSM, eih?

It has been suggested on IRC that they used GeoNames, which does
sometimes have very-strange-but-not-completely-wrong names.  But
GeoNames is already under a compatible license as far as I know.

 Would that poor old local name of Madrid be old_alt_loc_name=[whatever] in 
 OSM terms??

I checked the edits history and it wasn't under any of those tags, but
it would make sense to add it as loc_name, as people might sometimes
use Madriles in their search queries and such. :)  But it's not a name
you'd want to display on a serious map.

Cheers

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