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:[email protected]] > 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. _______________________________________________ Imports mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports
