<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
El 22/02/12 10:36, Ander Pijoan escribió:
<blockquote
cite="mid:CAMo0bbpNvcTavT1Eo8WPiwNoZNokNFvFWv0esLfmW2StM-s-wQ@mail.gmail.com"
type="cite">Recordad que estamos mas o menos pendientes de si hay
alguna mejor forma para el tag natural=water para denominar aguas
artificiales, pozos, piscinas, depósitos... En catastro a veces vienen
bien especificadas y en esos casos si que les ponemos su tag
correspondiente pero en un gran caso todas esas aguas artificiales
vienen como agua a secas y no sabemos cual es el mejor tag que se le
ajusta.<br>
</blockquote>
Si en catastro la única información que hay es que es agua, pero no se
sabe si es un pozo, una alberca, piscina, etc. cualquier asignación
automática que haga el programa acertará en algunos casos, pero en
otros no. Yo le pondría un natural=water y un "fixme=especificar tipo
de agua" para que se revise a mano.<br>
<br>
<blockquote
cite="mid:CAMo0bbpNvcTavT1Eo8WPiwNoZNokNFvFWv0esLfmW2StM-s-wQ@mail.gmail.com"
type="cite"><br>
También los edificios que ahora están saliendo como TourismAttraction,
tras probar en varios pueblos hemos visto que son principalmente
edificios que pertenecen a los ayuntamientos o al gobierno, por lo
tanto si conoceis otro tag que se le asemeje más lo modificamos.<br>
</blockquote>
amenity=public_building<br>
<blockquote
cite="mid:CAMo0bbpNvcTavT1Eo8WPiwNoZNokNFvFWv0esLfmW2StM-s-wQ@mail.gmail.com"
type="cite"><br>
Llevamos una semana un tanto liados pero poco a poco seguimos haciendo
pequeños cambios.<br>
<br>
Saludos.<br>
<br>
<div class="gmail_quote">El 22 de febrero de 2012 10:05, David <span
dir="ltr"><<a moz-do-not-send="true" href="mailto:cymerio@gmail.com">cymerio@gmail.com</a>></span>
escribió:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">¡Muy
buena pinta!<br>
<br>
<div class="gmail_quote">
<div class="im">El 20 de febrero de 2012 10:41, Ander Pijoan <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:ander.pijoan@deusto.es" target="_blank">ander.pijoan@deusto.es</a>></span>
escribió:<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Os
traemos hoy una curiosa imagen. Tenemos desplegado en local nosotros
para nuestras pruebas un servidor Mapnik en el que hoy hemos volcado el
resultado de cat2osm de Ciudad Real, después de reparar los errores que
tenía. Como la caché de imágenes conserva las antiguas aquí tenéis una
buena comparación del antes y después.
<div>
<div class="h5"><br>
<br>
<a moz-do-not-send="true" href="http://i.imgur.com/0miKR.png"
target="_blank">http://i.imgur.com/0miKR.png</a><br>
<br>
Saludos.<br>
<br>
<div class="gmail_quote">El 19 de febrero de 2012 19:02, sergio
sevillano <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sergiosevillano.mail@gmail.com" target="_blank">sergiosevillano.mail@gmail.com</a>></span>
escribió:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div>
<div style="word-wrap: break-word;">
<div>en general veo que el catastro tiene "sus cosas"</div>
<div>y requiere trabajo manual</div>
<div><br>
</div>
<div>gracias por mirarlo</div>
<div>si no tienen solución por lo menos queda como </div>
<div>cosas en las que fijarse antes de subir a osm</div>
<div>
<div><br>
</div>
<div><br>
</div>
<div>El 17/02/2012, a las 12:22, Ander Pijoan escribió:</div>
<div><br>
<blockquote type="cite">@sergiosevillano.mail en <a
moz-do-not-send="true" href="http://gmail.com/" target="_blank">gmail.com</a>
<br>
<br>
>VP_0000_all;<br>
>VP_0001_cauceNoEsFarm_EsNada; polígonos estrechos muy largos suelen
ser cauces o caminos, no subir, dejar hueco<br>
>VP_0002_CaminoNoEsFarm_EsNada; polígonos estrechos muy largos
suelen ser cauces o caminos, no subir, dejar hueco<br>
<br>
Entendemos que lo que comentas es que no se suba el polígono que
representa el hueco entre parcelas delimitadas por un río o carretera.
Es complicado ya tendríamos que mirar como hacer que el programa
entienda cuando es un polígono de esos porque no llevan ningún tag
especial.<br>
<br>
>VP_0003_streamNoEsLimite; a veces los arroyos (stream o river) no
dividen las parcelas si a ambos lados son la misma<br>
<br>
En catastro se representan así, no cortan una parcela. No se muy bien
como querrías representarlo de otra manera.<br>
<br>
</blockquote>
<div><br>
</div>
</div>
<div>mi sugerencia es que si realmente el río está en la
parcela y ésta no se divide en dos, la línea del río no debe incluirse
como un miembro de la relación de la parcela. </div>
<div>
<div><br>
</div>
<br>
<blockquote type="cite">>VP_0004_streamDireccionesERR; el
sentido del río (que debe coincidir con el de la vía) no es congruente
se divide en dos y uno de ellos acaba, luego éste tiene sentido erróneo.<br>
<br>
No nos habíamos dado cuenta de que en OSM los ríos se indicase en su
sentido. Esto en catastro seguramente no esté contemplado por lo que
habría que invertir la vía desde JOSM.<br>
<br>
>VP_0005_farmNoEsScree; el tag scree se refiere a pedregal de alta
montaña (Canchal) creo que viene de improductivo en el catastro no
tiene traducción para osm, dejar vacío<br>
<br>
En la imagen pone scrub. De todas formas scree se ha descartado hace un
tiempo.<br>
<br>
</blockquote>
<div><br>
</div>
</div>
<div>ups, fallo mío</div>
<div><br>
<blockquote type="cite">>VP_0006_huertoNoEsScrub; scrub es
matorral, pero esto no lo es parece huerto (no sé en osm, quizás
también farm)<br>
<br>
Esto tiene pinta de ser datos incorrectos en el catastro porque ese
scrub viene de que lo han catalogado como suelo improductivo.<br>
<br>
>VP_0007_FarmEsIgualAFarmland; en la wiki landuse=farm es lo mismo
que landuse=farmland deberíamos elegir uno, parece preferible
landuse=farm (tierras de cultivo) no confundir con landuse=farmyard que
es donde están las construcciones de granja apero almacenes ...<br>
>VP_0008_NoScreeNoFarmSiFarmyard; ver VP_0007<br>
>VP_0009_NoFarmSiFarmyardFaltaBuilding;<br>
>VP_0012_NoFarmSiFarmyard; edificio de granja esta siempre en
landuse=farmyard y no en landuse=farm, ver VP_0007<br>
<br>
En catastro no hay una categoría para granja o edificios de granja. El
decirle al programa que toda construcción que encuentre sobre un
landuse=farm lo convierta a farmyard puede ser peor porque pueden ser
viviendas, silos, etc. etc.<br>
<br>
>VP_0010_SiScrub; el matorral está en parcela residencial<br>
>VP_0011_NoScrub; un edificio no puede ser natural=scrub<br>
<br>
Esto seguramente sea porque pertenecen a los datos rústicos del
catastro. A estos datos por ser rústicos hay que añadirles un tipo de
cultivo de la parcela y tendrá como cultivo asociado improductivo. Lo
único que se podría hacer es introducir bloqueos. En este caso ¿cuales
serían los bloqueos? ¿landuse=residencial no puede tener tipo de
cultivo que en este caso se traduce en natural=scrub?<br>
<br>
</blockquote>
<div><br>
</div>
</div>
<div>parece que "terreno improductivo" es lo que más errores
genera . quizás eliminaría todo terreno improductivo de la importación. </div>
<div>ésta definición es negativa, y no sé si hay tag para
terreno improductivo en general, aunque sí hay para cosas que son
improductivas:</div>
<div>de hecho todos los landuse excepto los de cultivo (que son
farm, orchard, vineyard, grass, forest), son "improductivos".</div>
<div><a moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/ES:Map_Features#Uso_del_suelo_.28Landuse.29"
target="_blank">http://wiki.openstreetmap.org/wiki/ES:Map_Features#Uso_del_suelo_.28Landuse.29</a></div>
<div><br>
</div>
<div>lo que es cierto es que no todo lo improductivo es scrub</div>
<div>por ejemplo a todo el casco urbano se le aplica scrub !?</div>
<div>
<div><br>
</div>
<div><br>
</div>
<br>
<blockquote type="cite">>VP_0013_SegmentoPerdidoOverRio; el
rio se usa como línea que divide cultivos y miembro de relaciones, pero
en este segmento tenemos 2 vías superpuestas una con las relaciones y
otra con el río solo.<br>
<br>
Esto es una chapuza de los que hayan hecho la importación, cada pueblo
tiene sus sorpresas.<br>
<br>
>VP_0014_SinTagsRelevantes; vías y relaciones sin ningún tag que lo
identifique como algo de osm, solo tiene refs del catastro y source..<br>
<br>
Esto significa que esa casa no tiene ningún registro en el catastro.
Solo tenemos su geometría en los shapefiles y no hay datos extra del
archivo .cat. <br>
<br>
>VP_0015_NoWater; natural=water es tag de vías cerradas o o tag de
relaciones multipoligono, nunca un segmento suelto puede tener tag de
área. ademas el propio tag no es correcto la relacion superior ya dice
que es piscina luego no es natural=water. (porque los segmentos no
están unidos en una sola vía cerrada?)<br>
<br>
Esto esta explicado en la wiki, las piscinas, pozos, etc tienen las
geometrías partidas de origen (de formas muy entretenidas).<br>
<br>
</blockquote>
<div><br>
</div>
</div>
<div>de acuerdo, pero nunca son natural=water. en osm (que
básicamente es lago natural)</div>
<div>tenemos piscina, deposito, estanque, fuente...(todo
artificial) </div>
<div>alguno parece registro de aguas que no sé que sería en
osm..</div>
<div>puede que la solución sea saber el error y simplemente
chequear todos ellos a mano uno a uno.</div>
<div><br>
<blockquote type="cite">>VP_0015_NoLanduseHealth; no existe
landuse=health, se podría sustituir por amenity=hospital hasta que nos
aclaremos en osm con: <a moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0"
target="_blank">http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0</a>
,<a moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare"
target="_blank">http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare</a>
<br>
<br>
Sabemos que hay cierta pelea con esto, nos reocmendaron usar
landuse=health como forma de hacer lobby, supongo.<br>
</blockquote>
<div><br>
</div>
</div>
<div>donde está documentado landuse=health ?</div>
<div>sí he encontrado que la relación tenga un type=health</div>
<div><a moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0#Usage_of_the_health-relation"
target="_blank">http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0#Usage_of_the_health-relation</a></div>
<div><br>
<blockquote type="cite"><br>
> VP_0016_Scrubdentrodeedificio; un multipolígono edificio contiene
(dentro no a modo de patio) otro mas pequeño que es matorral (scrub),
no puede ser, parece que quería ser edificio con patio jardín y el
edificio estrecho es mas bien barier=wall que sería lineal .esto último
es mejor a mano....<br>
<br>
Esto es tema de las "geometrías interesantes" de catastro. Poco se
puede hacer.<br>
<br>
Saludos.<br>
<br>
-- <br>
<div><font color="#666666">Ander Pijoan Lamas</font></div>
</blockquote>
<br>
</div>
</div>
<div>
<div><br>
</div>
<div><br>
</div>
<div>ademas de lo anterior en el mismo archivo osm de
Villanueva de Perales</div>
<div>esta lo que comenté de que el contorno urbano está marcado
como scrub</div>
<div>y:</div>
<div><br>
</div>
<div>
<div>VP_0017_CemeteryNoIndustrial; un cementerio es
landuse=industrial?</div>
<div>VP_0018_DuplicacionNoGrave_yard; no puede haber un nodo y
un área para la misma cosa (landuse=cemetery), además el nodo tiene
icorrectamete el tag amenity=grave_yard (tumbas al lado de iglesia) y
el nombre no puede ser el genérico "CEMENTERIO" (quitar mayúsculas),
eso ya lo dice el tag. si no se sabe nombre propio quitar tag name=*</div>
<div>VP_0019_TourismAttractionCual; esta marcado como atracción
turística pero no se sabe cual, falta nombre o por lo menos qué tipo:
ayuntamiento, palacio, museo.... </div>
</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>si queréis las fotos de esto decídmelo y os la mando
directamente a vuestro mail.</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>