Land use throughout the Gironde department was carried out from the BD-ORTHO (2004 campaign), provided by IGN.
In the absence of a near-infrared spectral band allowing in particular to discriminate against vegetation by remote sensing, the department was mapped mainly by photo-interpretation. For a desired rendering at 1/10,000th, vectorisation took place at 1/5 000th. ArcView 8.3 software was used for this task.
The vector data obtained is a surface layer containing 99,542 objects, cut according to the department’s right-of-way (surface layer provided).
The polygons were optimised topologically after detection of duplicates, overlaps, multi and micro polygons as well as “empty” areas due to a failure to hang at the vertices.
The final file is called “OCS_GIRONDE”. This layer shall include as assigned data:
— the unique identifier for each record, field “ID”.
— the code relating to a class, field ‘CODE’;
— the heading relating to a class, field ‘INTITULE’;
— the surface in ha, field ‘SURFACE_HA’;
The number of classes determined is 18. Each class corresponds to a number (field “CODE”) and a denomination (field “INTITULE”).
The different classes are listed in the table available under the heading “Resources”
The “URBAIN DENSES ZONES” have been assimilated to built areas for which the dwellings are contiguous. On the other hand, the majority of the urban area of the CUB contained within the boundary formed by the Rocade was affected in this class.
For “ZONES BOISEES”, discrimination between hardwood and coniferous forests could not be precisely established due to the spectral domain swept away by the ortho (visible) comics.
The “sediments” class includes all the elements that emerge at low tide.
Build on reliable and scalable technology
FAQ
Frequently Asked Questions
Some basic informations about API Store ®.
Operation and development of APIs are currently fully funded by company Apitalks and its usage is for free.
Yes, you can.
All important information such as time of last update, license and other information are in response of each API call.
In case of major update that would not be compatible with previous version of API, we keep for 30 days both versions so you will have enough time to transfer to new version. We will inform you about the changes in advance by e-mail.