[Imports] Spanish cadastre

Ander Pijoan ander.pijoan at deusto.es
Fri Mar 23 11:10:49 UTC 2012

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.


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


> Are you really going to import all parcels ?

Yes, all parcels that have/we can give SIGNIFICATIVE metadata.

> Here in France, we had a very large consensus to refuse the parcels.
> Parcels are changing frequently (more than buildings) and are overloading
> the data density which is already at the limits with individual buildings
> addresses. And parcels are not 1:1 with landuse. Many landuse single
> can group a lot of parcels or a single parcel may contain different

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)


> Your community should really reconsider the pros
> and cons of parcels import. What does it bring to OSM ?

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.

> Nobody can modify them, they are not verifiable.

We are disscussing a "cross validation" scheme to improve and validate
these (and other) information.

> It makes manual editions very complicated.

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".

> It does not really help for tagging other things
> (excepted some fences or walls as we do manually in France but we use
> the parcels as an external source with a seperate WMS layout in the
> editor).

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).

> Pieren

Thanks for your comments.

>penorman at mac.com

>What is your proposed tagging of these objects?

>Cadastre generally have a lot of detailed information, not all of which is
>suitable for importing into OSM. Which datasets do you intend to import and
>which do you intend to leave out?

We have a wiki page with the tag traduction (sorry, yet it is only in


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).

> What software do you plan to use to conflate with existing OSM data?
> How do you intend to upload the data?

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.

> I suggest breaking your import proposal into sub-proposals for each type
>data set. E.g. have a different proposal for roads than for buildings.

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


for more information.

> Could you produce sample .osm files for a small area, one for each data
> source (shapefile) from the castrade?

Yes we can. They are divided in municipalities and inside every
municipalitie it is divided in themes (builds, parcels, roads, etc).

> I also see that according to Google translate you are proposing having a
> for the surface area (SUPERFICIE CATASTRAL (metros cuadrados)).
> If that translation is accurate, this is a bad idea. The area of a closed
> can be computed from the way and should not be a separate tag.

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.

> Which of these are you proposing to import?

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

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.

(if it does not work, enter first just the root url then click on OpenLayers)

Thanks for your comments.

Ander Pijoan Lamas
Ingeniero Técnico en Informática de Gestión
Universidad de Deusto

Email: ander.pijoan at deusto.es
Móvil: +34 664471228
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20120323/4ffed594/attachment.html>

More information about the Imports mailing list