OpenStreetMap logo OpenStreetMap

Changeset When Comment
28353164 almost 11 years ago

Eso creo quedo como querias, tenes que esperar un rato (depende de la escala) y/o actualizar el cache para que aparezcan en el mapa.

Lo que necesito que me expliques son las 9 restricciones que agregaste, para ver si se corresponden con lo que quisiste agregar, o hay que corregir alguna. (Algunas parecen razonables, otras quizas no tanto, aunque a veces los que hacen las reglas del transito piensan distinto)

28348901 almost 11 years ago

Revertido.

@aguiarjuliano: Por favor, leer la documentacion de la etiqueta building.

28353164 almost 11 years ago

Hola. ¿Podrias explicar que restricciones intentaste agregar en este cambio?

28308200 almost 11 years ago

Las restricciones agregadas indican que no se permite el paso de bicicletas (ej. bicycle=no ), cosa que no refleja la realidad.

28308168 almost 11 years ago

Cambio revertido. El punto no era vacio. Indicaba un desfibrilador.

28118804 almost 11 years ago

@facucaldo: En OSM hay que poner un elemento de OSM por cada elemento de la realidad. Como caso de ejemplo, hay que poner un solo amenity=hospital, no dos como quedaron con este cambio, uno en la via y otro en el nodo.

27395890 almost 11 years ago

La restriccion de giro es no doblar a la izquierda, asi que reverti ese detalle.

19942512 almost 11 years ago

If the note says that do not add natural=water to the relation relation/2195612, should'nt be the same with water=lake?

28007367 almost 11 years ago

Hay que tener mas cuidado con los cambios que involucran limites. Habian quedado mal los de Cerro Chato, pero tambien los departamentales de Durazno y Florida.

28018797 almost 11 years ago

NOOOOOOO!!!!! Esto esta directamente equivocado. De ninguna manera se puede usar datos o imagenes de Google para agregarlos a OSM porque Google no lo permite.

28020277 almost 11 years ago

Tendrias que revisar expresamente la compatibilidad de agregar datos de MOTVMA a OSM. Lo que dice en http://sit.mvotma.gub.uy/shapefiles.htm (especificamente los puntos 2 y 4) parecen ser no compatibles. La resolucion ministerial puede verse en http://sit.mvotma.gub.uy/recursos/rm902-2011.pdf

Te invito a discutir el asunto en la lista talk-uy antes de seguir usando esta fuente de informacion.

28008569 almost 11 years ago

OK Sergio. Lo importante funcionalmente es que hay que dejar bien claro que el cruce del rio no es un tramo ruteable para un vehiculo normal. Como minimo, etiquetar 4wd_only=yes y evaluar si eso es suficiente para que los softwares de ruteo interpreten que por ahi no puede circular un vehiculo normal.
¿Entiendes mi opinion?

28008569 almost 11 years ago

La clasificacion de vias cruzando el Rio Yaguaron no es correcta. Por lo menos no parece posible cruzarlo en un vehiculo normal.
Creo que habria que revisarlo mejor.

En cuanto al resto, no importa que sea un camino que una dos paises, por eso no se le sube la categoria. Ademas es la categozacion convenida vigente
por el Proyecto Uruguay.

27555878 about 11 years ago

Esto es un error. Es trunk por convencion. Favor de ver el wiki del Proyecto Uruguay.

27520363 about 11 years ago

El tema de como etiquetar las estaciones de tren hay que revisarlo. En el contexto de OSM las "railway=station" son para servicio de pasajeros, y con la desactivacion casi completa de los servicios que hubo en Uruguay la unica que queda es la que va de Central a 25 de Agosto. Creo que tener marcadas o marcar el resto como servicio de pasajeros es algo que da para malas interpretaciones. Una "estacion" en este nuevo contexto no es mucho mas que un edificio.

27495110 about 11 years ago

Es algo discutible. Las manzanas dibujadas como vias representan las manzanas en si mismas. Pasarlas a multipoligonos puede empeorar la calidad del dato, porque las vias representan el eje de cada calle, y no la manzana en si. O sea la representacion anterior puede ser (en teoria) es mas exacta.

27378337 about 11 years ago

(que el mapa no renderice ambos quise decir)

27378337 about 11 years ago

Gracias a vos. Igual tene en cuenta que lleva el mismo nombre, porque el boundary=administrative con admin_level=8 y el nodo representan lo mismo (con distinto nivel de detalle), y corresponden que esten ambos.
Lo que seria mejor es que el mapa renderice a ambos, pero eso es problema del render y no de los datos.
Capaz que para eso habria que hacer dos relaciones iguales y una solo con el landuse=residential, pero igual es mapear mas para evitar que el render cometa el error. Al estar los datos bien, la responsabilidad de dibujar bien el mapa tiene que estar del lado del render.

27378337 about 11 years ago

No es correcto quitar el nombre. El nombre corresponde que esté.

27338779 about 11 years ago

Bien. Te invito al foro OSM Argentina para tratar este tema. http://forum.openstreetmap.org/viewtopic.php?pid=470212

Reverti tu cambio porque me parece que estas confundido.