[OSM-talk] All you've ever wanted to know about the french cadastre

[Lester Caine]

Martin Koppenhoefer wrote:
>> Personally I would prefer to see
>> >http://www.remote.org/frederik/tmp/funnybuilding.png  as a single closed
>> >outline box.
>
> I think that 6-7 buildings (looking at the bing aerial
> http://it.bing.com/maps/?v=2&cp=44.277739~0.502686&lvl=20&dir=0&sty=h&where1=44,277748%200,502839&form=LMLTCC
>   , maybe there is more but on a first remote approximation I could see
> 6 or 7) would be much better than a "single closed outline box",
> especially, if the tag is something like building=yes which is used
> for "one" building, not groups of them.
>
> There is a really huge difference between 1 big building and 7
> adjacent small ones. The problem is, that the cadastre version doesn't
> seem to make sense when compared to the aerial imagery. It is better
> to have detailed outlines, but only if this detail is depicting
> reality.

Certainly looking at the bing image there seemed to be a major difference 
between what was drawn and the difference in roof structure. And the overall 
shape. THIS is where being able to access the raw import data would be useful as 
a comparison ... if only to identify where the import process is breaking down?

I'm seeing EXACTLY the same sorts of problem with the UK data which I have 
already indicated. I can pull up OS Streetview, bing, and in some cases historic 
maps and see the differences. It was THIS situation which prompted me originally 
to look into how the French data was handling it, and I think that it's exactly 
the same problem! I have referred to 'trusted' data sources, but I do not think 
any of these sources come into that category, while 'boundaryline', and the 
French 'landuse' (? which that is) could be treated as 'trusted'? What data can 
be imported and updated automatically?

While some government data has been made 'open source', the KEY material is 
still locked down! :( Identifying the number of buildings in a block would be 
easy if we had a list of individual buildings and their location. The UK NLPG 
data has that list, but we can't use it. Also in the same way as the French data 
quality varies from town to town, the data within NLPG has the same vast 
differences in quality, and in many cases relies on the well out of data OS 
streetview data. Can the cadastre data be accessed as a list? I presume not as 
I'm sure you would be using it as a cross-check, but it's this 'building list' 
that is the key to ensuring that each identifiable building is displayed on OSM 
in the future. In the case of NLPG this will only identify a 'property' which 
will not necessarily count detached garages and outbuildings unless they are 
under separate ownership, and I would anticipate the same in the cadastre data?

All the discussions here are very much interrelated ( I don't do politics so I 
ignore that debate ) ... The discussion on 'adding layers' is to a certain 
extent academic. We ARE already using layers in the editors, and using 
http://www.openstreetmap.org/?lat=44.2777468264103&lon=0.502683520317078&zoom=19 
as our current example, edit gives the potlatch view with bing and there is a 
major discrepancy between the two layers. It would be nice here if the cadastre 
import was also available as the OS Streetview is on UK areas. With such a long 
set of threads I've forgotten and can't find who said that OSM had specific to 
USE the cadastre imagery in the editors :( I can understand why a local group 
MANAGING an import source might not want it generally available, but I think 
there needs to be a good reason not to?

At the end of the day, what we need to decide is what level of accuracy is 
acceptable, and while I don't think we want to be getting to a level where 
measurements of OSM can be used to settle property boundary disputes, the 
information imparted should represent the ground conditions as accurately as 
possible. I decided against importing buildings from streetview because it IS 
too far from reality. Claims are being made that the French data is more up to 
date, but if it is not being properly geo-referenced and is producing poor 
quality data should it be allowed in? returning to the example, in the absence 
of evidence that the building IS split into multiple units it SHOULD be drawn as 
a single entity? And tidying up would mean aligning it with the bing footprint? 
NONE of the buildings in the vicinity are of a quality that I would be happy to 
commit at which point I'd like to see the raw data and work out where the 
problem is. Some buildings are actually quite accurate, so the positioning is 
good, I get the same on streetview where I KNOW the build has been constructed 
in the last 5 years! But then the buildings around can be up to 50% off. I moved 
down to the village below the example building ...

Moving this forward ...
I think we are getting to a point where 'staging' or 'construction' layers do 
make sense. And a few of them would also make sense as separately selectable 
layers in viewers. 'Boundaries', with a complete list of what SHOULD be present, 
and tagging on the 'placeholder' as to what has been completed. In the UK, the 
boundaryline' layers combined to provide a single data source. 'Highway' would 
be a bit more difficult, but should be 'doable'. 'Building' would be massif, but 
not impossible since things like the PAF data and the NLPG exist already. 
Cadastre is obviously the French equivalent, and I doubt any country in the 
world is not taxing properties in some way? Ignoring shanty towns and refuge 
camps at this stage ... although MAPPING refuge camps and disaster area is a 
service that would be appreciated on the ground! I have no doubt that the volume 
of data will continue to escalate, so providing a 'car/cycle/foot' layer without 
the clutter of all this fine detail would help the router processes, but they 
can still overlay the data on a detailed raster map. The example in software 
would sort of be 'namespace', we ring fence code in it's own namespace, so we 
can ring fence detail in 'layers' that can be ignored when creating some data 
feeds.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk