[ckan-dev] geo data modelling

Mon Nov 25 21:16:23 UTC 2013

hi phillip,

you have got the wrong link. here is the right one to a dataset which comes
from our geoportal (http://www.geoportal.rlp.de):
https://www.govdata.de/suchen/-/details/00a12e63-0550-c6be-c3bf-bb73307996a0

"fictive" means simply, that you have no metadata about the dataset itself,
just an ows - maybe wms or wfs. then you may use a layer/featuretype as a
dataset. means, that you use the metadata, that is corresponding to this
entity as metadata for a dataset. e.g. use the layer title as dataset title
and the layer_id or name as the dataset_name. as i told you, most of all
geodata - which is normally encoded as defined in iso19139, has no
relations between services and datasets :-( . as stated for geo-metadata
there should be a linkage from the service layer/featuretype object to one
or more dataset metadata. this relation is n <-> m and may be complicated.
we use the service/metadata information modell of our geoportal to generate
the json objects for ckan installations on the fly. because only 218 of
nearly 1200 "open" datasets have coupled metadata (at the moment we have
nearly 5000 datasets, which are available via ows), we build the json
objects directly from ows capabilities documents and some further data in
our information modell. if more coupled datasets become available in near
future, i will adopt the export handler to generate also consistent
dataset/resource objects.
here is the link to the webservice, which generates the ckan objects from
our postgis database:
http://www.geoportal.rlp.de/mapbender/php/mod_exportMapbenderLayer2CkanObjects.php

the ckan that we directly update via its api is here:
http://www.daten.rlp.de

here is one consistent example of geometadata which is conform to the
INSPIRE Directive and maybe used to build ckan objects:

dataset metadata:
http://www.geoportal.rlp.de/mapbender/php/mod_dataISOMetadata.php?outputFormat=iso19139&id=e9d22d13-e045-f0e0-25cc-1f146d681216

service metadata:
http://www.geoportal.rlp.de/mapbender/php/mod_layerISOMetadata.php?SERVICE=WMS&outputFormat=iso19139&Id=30825

view service capabilities document:
http://www.geoportal.rlp.de/mapbender/php/wms.php?layer_id=30825&PHPSESSID=0eeec8dbd3dfe7deea744b3f5268a212&INSPIRE=1&REQUEST=GetCapabilities&VERSION=1.1.1&SERVICE=WMS

download service capabilities document (INSPIRE ATOM Feed):
http://www.geoportal.rlp.de/mapbender/php/mod_inspireDownloadFeed.php?id=e9d22d13-e045-f0e0-25cc-1f146d681216&type=SERVICE&generateFrom=wfs&wfsid=216

if you have further questions - please ask me ;-)

(here is a my little presentation from the fossgis this year:
http://www.fossgis.de/konferenz/2013/programm/events/622.de.html - maybe an
online translation service can help?)

regards

armin

2013/11/25 Philippe Duchesne <pduchesne at gmail.com>

> Hello Armin,
>
> thank you for this information.
> However, browsing the geodata.gov.de site, i don't see an example of the
> mapping you mention. Can you point me to an example?
>
> Besides, while having a fairly good knowledge of OGC specs, i'm not sure i
> understand what you mean by a "fictive" feature type. Can you clarify?
>
> thank you,
>
> --p.
>
>
>
> On Mon, Nov 25, 2013 at 11:40 AM, Armin Retterath <
> armin.retterath at gmail.com> wrote:
>
>> hello phillip,
>>
>> we implemented a mapping between ogc resources and ckan objects. it is
>> relevant, that you map a dataset as dataset and the corresponding services
>> as resource endpoints. you may have a look at http://www.govdata.de.
>> in the ogc metadata concept, there is a relation from the service content
>> (layer/featuretype) to one or more dataset metadata. if you don't have the
>> relation, you may map a fictive layer/featuretype as a dataset object.
>> the problem with the ogc metadata is, that the relations are not well
>> maintained or don't exists. maybe the EU INSPIRE Directive will produce
>> more consistent metadata in this point of view.
>>
>> if you have further questions or need some practical examples please ask
>> ;-)
>>
>>
>> hope this helps a little bit
>>
>> regards
>> armin
>>
>>
>> 2013/11/25 Philippe Duchesne <philippe at okfn.be>
>>
>>>
>>> hello all,
>>>
>>> i have a data model design question for the geo-aware folks:
>>>
>>> i find the current way of storing W*S services in the CKAN model not
>>> adequate, in the sense that OGC resources (feature types, layers, ...)
>>> don't get captured.
>>> Rather, whole services are mapped into datasets, with resources
>>> containing capabilities, legend, and so forth.
>>>
>>> Wouldn't it be better to
>>>     - have a dataset per OGC service, and then a resource per
>>> layer/feature type
>>> or  - have a dataset per layer/feature type, as these deserve metadata
>>> on their own, and then a 'related' link to the service dataset
>>>
>>> does anyone else feel that need?
>>> are there any plans for something like that?
>>>
>>> thanks,
>>>
>>> Philippe Duchesne
>>> OKFN.be
>>>
>>> _______________________________________________
>>> ckan-dev mailing list
>>> ckan-dev at lists.okfn.org
>>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>>>
>>>
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>>
>>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20131125/59630091/attachment-0003.html>