[Imports] Spanish cadastre

[Paul Norman]

I have significant concerns, which I will expand on below. I have worked
with detailed parcel data before as well as seen parcel data elsewhere.

----
> From: Ander Pijoan [mailto:ander.pijoan at deusto.es] 
> Subject: [Imports] Spanish cadastre
----
> > Are you really going to import all parcels ?
> Yes, all parcels that have/we can give SIGNIFICATIVE metadata.

The experiences of other regions and my experiences locally with parcel data
is that it does not belong in OSM. I don't believe I am going too far in
saying that the consensus of the imports@ list is that parcel data should
not be imported.

> > 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 and
> > addresses. And parcels are not 1:1 with landuse. Many landuse single
polygon
> > can group a lot of parcels or a single parcel may contain different
landuse.

> 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)
>
>
http://wiki.openstreetmap.org/wiki/Traduccion_metadatos_catastro_a_map_featu
res

Hopefully this will become clearer when you provide the requested .osm file

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

The TIGER import has shown pretty conclusively that it is very easy to
overload 
an import with metadata which never gets edited or fixed.

> > Nobody can modify them, they are not verifiable.
>
> We are disscussing a "cross validation" scheme to improve and validate
these (and other) information.
	
The verification spoken of here isn't the type that you do with code and
computers, 
it's what you do when you're in front of the lot and want to verify the OSM
tagging is correct.

Will the information imported be verifiable in this sense?

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

The import guidelines prohibit imports that make editing very complicated in
the current editors. 


> > 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
spanish)
>
>
http://wiki.openstreetmap.org/wiki/Traduccion_metadatos_catastro_a_map_featu
res
>
> 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.

JOSM is not well suited for uploading lots of data. I think the best way is
to edit with JOSM and either upload small groups of objects at once or save
the .osm file, create a .osc file from it, sort it to keep ways near their
nodes and then upload it with one of the shell scripts.

> > 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.
>
> 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
>
> http://wiki.openstreetmap.org/wiki/Spanish_Cadastre/results
>	
> for more information.

The issue with structuring it as you have is that it is a massive amount of
proposed tagging to review.

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

Could you post a set of .osm files for one municipality then?

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

How can we tell on the wiki which tags will be used then?

> > 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 more.
>
> 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.
>
> http://130.206.138.173/OpenLayers
>
> (if it does not work, enter first just the root url http://130.206.138.173
and then click on OpenLayers)

Zooming in, it looks like this would make the area extremely hard to edit
with Potlatch. Have you tried editing areas mapped like this in PL2?

I note on http://wiki.openstreetmap.org/wiki/Spanish_Cadastre you say that
once the refinement process to cat2osm is done imports can start - this is
leaving out the discuss with imports@ of
http://wiki.openstreetmap.org/wiki/Import/Guidelines#Discuss_import_with_com
munity. I don't speak Spanish, but could you reword it so that no one
accidentally starts importing if cat2osm is finished before the issues are
ironed out that we're discussing?

Many of the people on the imports@ list have seen how imports can go wrong
and just don't want to see the Spanish community repeat mistakes that other
communities have made with imports.