[Imports] Spanish cadastre

[andrzej zaborowski]

Hi,

On 23 March 2012 22:37, Paul Norman <penorman at mac.com> wrote:
> 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.

I think the main value of the parcels data from the Cadastre is the
landuse classification which, if not imported, is going to be mapped
by local mappers anyway, likely spending more time and with results of
poorer quality.  See most of Germany.  It may be hard to edit in
Potlatch 2 (I don't know, haven't tried) despite being mapped with
lots of manual work.

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

The problem with TIGER I believe is that the converter added lots of
non-geographical data, some unverifiable and mostly easy to obtain
from TIGER itself provided that the tlid is maintained.

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

In JOSM, with chunked upload disabled (which I think is the default),
every upload is atomic, so the elements order doesn't matter.  When
uploading more than can be done in a single changeset, then yes, I'd
agree that the "smart" scripts should be used.

The Spanish Cadastre import is planned to be done only for data that
the uploader can verify (hopefully from own knowledge) and deduplicate
against existing OSM data, so they're likely to do it in manageably
small pieces.  Also the final decision on what is or isn't useful
remains with the local mapper.  The convert tool (cat2osm) tries to be
a generic converter between the two formats, which seems to be a good
choice.

Cheers