[Imports] Spanish cadastre

[Paul Norman]

> From: David Marín Carreño [mailto:davefx at gmail.com]
> Subject: Re: [Imports] Spanish cadastre
> 
> El 22 de marzo de 2012 20:38, Paul Norman <penorman at mac.com> escribió:
> >
> > > From: Carlos Dávila [mailto:cdavilam at orangecorreo.es]
> > > Sent: Thursday, March 22, 2012 5:28 AM
> > > To: imports at openstreetmap.org
> > > Subject: [Imports] Spanish cadastre
> > >
> > > Data from Spanish Cadastre is known to have a high accuracy and
> > > include a lot of information of interest for OSM project, such as
> > > buildings (shape, use, height, number of floors, etc.), rural and
> > > urban parcels land use, most of streets and roads of the country,
> > > power stations, tracks and paths, trees... Many of this information
> > > is currently in OSM, mainly ways and roads, but a great part is
> > > still missing, specially in low populated areas where a ground
> survey is less likely to be made.
> > > This import has been largely discussed on Spanish mailing list, with
> > > a general consensus on the usefulness of the import and a "we must
> do it"
> > > agreement.
> >
> > 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?
> >
> 
> The Spanish community has selected which objects are going to be
> imported, and how they will be tagged, using OSM wiki[1] (sorry, in
> Spanish).

I see that you are proposing importing land registry records. I believe this is a bad idea and the consensus is that land registry data is not suitable for import into OSM.

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

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

> 
> >
> > > Specific accounts have been created for the import, one for each
> > > Spanish province. There's a member of the Spanish community
> > > responsible of each province import.
> >
> > What software do you plan to use to conflate with existing OSM data?
> 
> JOSM (or other editor).
> 
> > How do you intend to upload the data?
> 
> Cadastre data is available for each municipality, and must be downloaded
> manually.
> 
> So, a collaborator will download Cadastre data for a municipality, and
> then will transform this data into OSM format using the new Cat2Osm
> tool. After that, using JOSM (or other editor), he will do the final
> checks and corrections before uploading it to OSM using the created
> account.
> 
> > Approximately how large will the changesets be?
> >
> 
> The current testing version of Cat2OSM is generating (for example) for
> "Puebla de Don Fadrique (Granada)"[2]:
> * 188177 nodes
> * 48421 ways
> * 19839 relations
> 
> For "Alcobendas (Madrid)"[3]:
> * 350092 nodes
> * 183413 ways
> * 67179 relations
> 
> Although this amounts will vary, as Cat2Osm is still being refined and
> corrected.

JOSM is not suited for uploading across multiple changesets. There are some tools that will sort a .osc file to have ways follow shortly after the nodes that make them up. If you upload directly from JOSM you will have a large number of nodes followed by the ways. If anything goes wrong, you will be left with stray nodes in the database. It would also be easy for a user to delete a stray node while you are uploading, causing you to have a conflict.

> 
> 
> >
> > I suggest breaking your import proposal into sub-proposals for each
> > type of data set. E.g. have a different proposal for roads than for
> buildings.
> >
> 
> Road imports would be exceptional (only in villages without previous OSM
> mapping), as the road data in Spanish Cadastre requires a lot of manual
> corrections before being imported into OSM.
> 
> Cat2Osm currently imports, among other data:
> * rural and urban parcels and subparcels, with their landuse (see [1])
> * type of crop in the case of farmlands, detailed at subparcel level
> * addr:housenumber and addr:street for urban parcels
> * buildings with their heights (if a building has different heights,
> this will be shown in the data, so this data could be used for 3d
> rendering)

Which of these are you proposing to import?

I still think breaking it into different proposals would be a good idea. The roads was just an example of two different datasets.