[NAS] Development of an NAS interface in GDAL/OGR

[Arnulf Christl]

Hi Matheuz, Frank,
GDAL/OGR users and potential sponsors have collected ideas and requirements towards a GDAL/OGR implementation for the German NAS interface. They are able to provide funding for this development. Before they can commit however, we have to produce a work plan and estimate costs for implementation. 

I will put together some preliminary information here and send it to the NAS mailing list and some individuals who are strategically involved with NAS. You find a list of standards documents here: 
http://www.adv-online.de/extdeu/broker.jsp?uMen=4b370024-769d-8801-e1f3-351ec0023010

Of relevance is the main document (verison 5), currently in German language only :-(
http://www.adv-online.de/extdeu/binarywriterservlet?imgUid=5be60b36-de06-8a01-e1f3-351ec0023010&uBasVariant=22222222-2222-2222-2222-222222222222&isDownload=true

The preliminary version 3 and 5 have been translated to English language:
http://www.adv-online.de/exteng/broker.jsp?uMen=01a700d3-6ed6-0bfb-8f23-50376a112976&sel_uCon=ba67086d-0d0d-6001-fde4-350376a11297&uTem=73d607d6-b048-65f1-80fa-29f08a07b51a.htm

NAS schema generator:
http://www.adv-online.de/extdeu/binarywriterservlet?imgUid=f465019a-8c61-b111-a3b2-1718a438ad1b&uBasVariant=22222222-2222-2222-2222-222222222222

What we need now is an estimate from you to evaluate implementation cost of a first prototype that we can use to raise funding. We need to have this estimate within the next four weeks and a working prototype (just that no more!) until the end of the year. On that basis we can then calculate a quality managed implementation that can be implemented in the first quarter of 2008. 

Please let me know if you need further information. 

Best regards, 
Arnulf.

== Introduction ==
With the introduction of the AAA concept the German geodesic world has taken a big step to standardization of cadastral bas map information in Germany. Find more information here: http://www.adv-online.de/

One part of the AAA model is the cadastral bas map named ALKIS. The complexity of the data model (free of redundancies, object oriented, common to all federal states, etc.) makes it really complex and thus prohibits using it efficiently in a scalable server infrastructure. For wide spread use it will be necessary to break down the complex structure and make it flat. This is good as it will make development a lot easier. The resulting converted flat data will only be used for query and visualization, maintenance and editing will continue in the proprietary geodesic systems. Updates come as differential files (NBA - user-specific updating of secondary databases) that must be integrated into the initial data set to keep up to date. 

== Open Source Option ==
There is no Open Source software that can access the original data directly as all current implementations are proprietary and as closed as possible (there are only three major vendors). There is a need for accessing this data using standard tools (Desktop GIS, CAD, web mapping services, web feature services). 

== Implementation in GDAL/OGR ==
One option to implement this most efficiently would be an extension to ogr2ogr. This would be a one-way lossy conversion that focuses on creating the basic geometry with as little overhead as needed, no topologies, with redundancy and a selected set of pre defined alphanumerical values. Find some more requirements as defined by potential users of the OGR module "nas2pgsql".

== Guiding ideas ==

1) NAS is (will become) the main interface to access ALKIS data (official cadastral base map and information). From current point of view data coming out of the NAS interface will serve two main use cases:
* WebGIS viewing and querying (search for parcel id, highlight result set)
* Excerpt for further use in non-AAA software (Desktop GIS, CAD, others)

2) The primary data has to be stored and maintained in proprietary systems. Therefore they must be converted to another format (eg PostgreSQL/PostGIS, Shape file) and updated using NBA (differential updates). Added value comes from being able to overlay, intersect and analyze with other spatial data and software. The proprietary ALKIS software cannot do this and even if it could it would be way, way too expensive and complicated for most users. Secondary spatial "products" could be WMS, WFS, GML export, etc.

3) The officially certified visualization (that sucks!) is desirable but not required! For this use case the official public administration can always fall back using the proprietary tools. 

== Requirements ==
a) Develop an NAS interface converter software that implements requirements as they come starting with a minimal set. Ideally the implementation should be extensible to fulfill requirements that come in at a later date without blocking issues.  

b) Minimal starting point it to create geometries for land parcels, buildings and connect both with the respective parcel numbers or street addresses. 

c) Defer "officially certified" cartographic visualization for a later date (if at all required) and when there is funding.