Hello, we are de developers of Cat2Osm and we are working back to back with the Spanish OSM community to know what the actual needs for OSM are, what is usefull and what useless. We have shown our results at the Open GIS Workshop in Girona and lots of enterprises are interested in having these data in OSM.<br>
<br><a href="http://www.sigte.udg.edu/jornadassiglibre2012/programa/jornadas">http://www.sigte.udg.edu/jornadassiglibre2012/programa/jornadas</a><br><br>We also prepared an OSM workshop at Deusto University to learn more about how OSM works, what can OSM do for us and most important what can we do for OSM.<br>
<br><a href="http://wiki.openstreetmap.org/wiki/Jornadas_OpenStreetMaps_Deusto_2011">http://wiki.openstreetmap.org/wiki/Jornadas_OpenStreetMaps_Deusto_2011</a><br><div class="gmail_quote"><br>> Are you really going to import all parcels ?<br>
<br>Yes, all parcels that have/we can give SIGNIFICATIVE metadata.<br><br>> Here in France, we had a very large consensus to refuse the parcels.<br>> Parcels are changing frequently (more than buildings) and are overloading<br>
> the data density which is already at the limits with individual buildings and<br>> addresses. And parcels are not 1:1 with landuse. Many landuse single polygon<br>> can group a lot of parcels or a single parcel may contain different landuse.<br>
<br>Shapefiles provide by Spanish Cadastre include a "subparcel" geometry with the diferent landuses for every parcel at least in the rural areas. For the urban area they provide the "use destination" but it is not directly linked to any geometry. This information will NOT be imported unless there is trivial way to assing these "use destinations" (only one building geometry, or similar cases). For all the destinations belonging to a certain parcel, we will infer a general landuse for that parcel and/or the buildings accodirng with the logic and metadata we have consensus in the wikipage (sorry, yet it is only in spanish)<br>
<br><a href="http://wiki.openstreetmap.org/wiki/Traduccion_metadatos_catastro_a_map_features" target="_blank">http://wiki.openstreetmap.org/wiki/Traduccion_metadatos_catastro_a_map_features</a><br><br>> Your community should really reconsider the pros<br>
> and cons of parcels import. What does it bring to OSM ?<br><br>This have been discused and my personal point of view is that this metadata, joined with all the other data already provide in the databas, make possible to do interesting research in the enviormental area. Moreover, we know that firefighters are working in a system using OSM data for routing and planing of their action (in case of emergency and in preventive action). We think that this information would be VERY interesting for them also.<br>
<br>> Nobody can modify them, they are not verifiable.<br><br>We are disscussing a "cross validation" scheme to improve and validate these (and other) information.<br><br>> It makes manual editions very complicated.<br>
<br>This is a problem of the editor not of the data itself. Editor should advance to "context based system" and not continued using the old scheme of "one interface to do all".<br><br>> It does not really help for tagging other things<br>
> (excepted some fences or walls as we do manually in France but we use<br>> the parcels as an external source with a seperate WMS layout in the<br>> editor).<br><br>And, what is the difference? I don't kwon how is divided the land is France but in Spain a LOT of parcel are divided by walls, fences and the like. So importing the parcels would be the same as taging the divisions (plus we gain the landuses of the subparcels).<br>
<br>> Pieren<br><br>Thanks for your comments.<br><br><br>>penorman at <a href="http://mac.com" target="_blank">mac.com</a><br><br>>What is your proposed tagging of these objects?<br><br>>Cadastre generally have a lot of detailed information, not all of which is<br>
>suitable for importing into OSM. Which datasets do you intend to import and<br>>which do you intend to leave out?<br><br>We have a wiki page with the tag traduction (sorry, yet it is only in spanish)<br><br><a href="http://wiki.openstreetmap.org/wiki/Traduccion_metadatos_catastro_a_map_features" target="_blank">http://wiki.openstreetmap.org/wiki/Traduccion_metadatos_catastro_a_map_features</a><br>
<br>We will only import data that already has a tag in OSM (except in three or four special cases like local sports areas, or local crops).<br><br>> What software do you plan to use to conflate with existing OSM data?<br>
> How do you intend to upload the data?<br><br>We will use OSM and a LOOOT of manual editing. We are talking on doing a "context based editor" with diferents interfaces suited for ONE single task.<br><br>> I suggest breaking your import proposal into sub-proposals for each type of<br>
>data set. E.g. have a different proposal for roads than for buildings.<br><br>Actualy, the data are divided in municipalities. We ar currently discused in doing a "tile base import" of bigger municipalitie but it is likely that we ended ussing the sub-proposals schame you are suggested. We think that should be a decision of the local comunity (we are organising the import in provinces with a coordinator and several local members that lock the municipalitie where they are working (or the tile in the case of big municipalities). All this coordination is made in the wiki. Please consult<br>
<br><a href="http://wiki.openstreetmap.org/wiki/Spanish_Cadastre/results" target="_blank">http://wiki.openstreetmap.org/wiki/Spanish_Cadastre/results</a><br><br>for more information.<br><br>> Could you produce sample .osm files for a small area, one for each data<br>
> source (shapefile) from the castrade?<br><br>Yes we can. They are divided in municipalities and inside every municipalitie it is divided in themes (builds, parcels, roads, etc).<br><br>> I also see that according to Google translate you are proposing having a tag<br>
> for the surface area (SUPERFICIE CATASTRAL (metros cuadrados)).<br>> If that translation is accurate, this is a bad idea. The area of a closed way<br>> can be computed from the way and should not be a separate tag.<br>
<br>On the wiki there are the proposed tags (just which would be the exact translation) but not all are going to be used. This tag is used internally in our scripts for asigning certain tags.<br><br>> Which of these are you proposing to import?<br>
<br>All information that have interest. We understand interest by "ALREADY exist a tag suited for that information or a VERY SIMILAR one". The only freedom we are taking is ussing tags for the 2.5D openstreetmap and little more.<br>
<br>Here is a SAMPLE TEST of an importation we made one month ago in our local server. With the new improvements the result will be more accurate but just as an example here you can see the difference with the uploaded data.<br>
<br><a href="http://130.206.138.173/OpenLayers" target="_blank">http://130.206.138.173/OpenLayers</a><br><br>(if it does not work, enter first just the root url <a href="http://130.206.138.173" target="_blank">http://130.206.138.173</a> and then click on OpenLayers)<br>
<br>Thanks for your comments.<span class="HOEnZb"><font color="#888888"><br clear="all"><br>-- <br><div><font color="#666666">Ander Pijoan Lamas</font></div><div><font color="#666666">Ingeniero Técnico en Informática de Gestión</font></div>
<div><font color="#666666">Universidad de Deusto</font></div>
<div><font color="#666666"></font> </div><div><font color="#666666">Contacto:</font></div><div><font color="#666666">Email: </font><a href="mailto:ander.pijoan@deusto.es" target="_blank"><font color="#666666">ander.pijoan@deusto.es</font></a></div>
<div><font color="#666666">Móvil: <a href="tel:%2B34%20664471228" value="+34664471228" target="_blank">+34 664471228</a></font></div><br>
</font></span></div>