[Freegis-list] Re: Freegis-list digest, Vol 1 #339 - 4 msgs

[Alfred de Jager]

Metadata revisited

Many reactions, useful reactions and quite cumbersome to comment in emails on it.
I' ll give it a try and I come up with a proposal that might interest you.

Mr Keller,

When trying to comprehend all the links you send for implementing a swiss gi infrastructure, my main wonder was if this aiming at the swiss context only or are you interested to go beyond that?
Besides the swiss context of course the progress of the project and the implementation issues might be of interest of everybody.
The interlis language seemed to me more a translator. Useful but I pinpointed that the main issue of data transfer is unique identification of normalized objects, technical tools are necessary though but not the main reason why gi metadata is not working yet (..)

Thus the contact person must have a number or a unique name (I proposed an email address, I know of the limitations of the latter)
For the data set similar problem arises, I proposed the physical location on a disk as unique identification. In a database that would be the full 'schema'. Also this has known limitations.
All other objects to be added will obtain the same problem. If I write that the source of my swiss data is the
suisse landesvermessungsamt and you send me an xml sheet in which you call it bundesamt fur Landestopographie meaning the same than no computer system will be able to make the link.
Thus if we want to define any organization as a data source than we ought to make a world wide web service giving a unique id to any organization that can be a data source for geoinformation. That is nothing new, booksellers happen to do that already for decades using their isbn number.
Therefore the whole ISO excercise is useful but should lead to the implementation of world wide ids of any normalizable object defined in it.
More or less this is happening now through openGIS initiatives, e.g. concerning spatial reference systems.

Storing XML.
Of course you can store an XML sheet and that is always better than storing a .doc. But is it difficult to search through it and consequently to index it. Currently many skilled programmers are busy in making XML sheets stored in databases searchable and indexable, a bit alike search engines index web pages. But I think that the GI Metadata, especially after essentialisation are so limited that we simply do not need all that overhead. Just store the fields of the XML sheet as normal strings, dates and numbers in your database and make searching and updating fast by default.

--------------------------------------------------------------------------------------------------------

Mr Lehmann,

A simple solution is not existing as you already found out.
If you use a webbased solution than the risk to anticipate on is that your metadata and the data itself are detached.
Thus the risk of inconsistency between both is large. (you move the data to another disk and then what happens to the metadata?)

Concerning European projection systems.
They do not exists as well. Europe being too large for one projection system in the first place. European wide maps are often presented in Lambert Equal Area projections, UTM or Albert projections. Lambert projections start to distort when bypassing an extent over 1000 kms. In that respect Albert can be more useful for continental mapping.
The trend is to store data in lat/long based on the so-called etrs 1989 reference and project only when presenting the data on screen or maps. Most GIS packages are able to do so by now.
A list of locally used projection systems commonly used in some european countries can be found on our service

http://www.aris.sai.jrc.it/cgi-bin/tl1.pl?tl1.pl+countries+countries.id

so for a european wide project you deproject the local data to etrs and alike create a database for whole continent.
this counts also for imagery data. In that case you use a cylindrical plate carree projection in which you should correct the area statistics of your data while going south-north since the plate carre projection does not conserve area.

--------------------------------------------------------------------------------------------

Mr Maki,

Yes I would be most interested to see your model. Especially the sql create table scripts!
Also I agree that while using large databases, an element based approach is needed.
I proposed this also for a new gi datamodel in the EU commission. Something more about this you find on
http://www.aris.sai.jrc.it/en/software/giscoentities.html
Note that such an approach also might lead to a 'metadata' loop. What I mean is that at a certain moment one can create so much metadata at element level that the essential data gets lost in the process. That is why I urge for 'essentialisation'.

It is also the case that all to my knowledge gi metadata initiatives are not addressing the issue of metadata at element level. It is focussing on 'describing' a set of data. Hence the difference could be a pointer at technical level, so I am not that worried.

-----------------------------------------------------------------------------------------------

Mr Batz(?)

The described Canadian situation complies with the general European situation. Though I find it difficult to prove that the lack of affordable GI data has measurable economical impact.
My feeling is that a lot of GI data is available but we lack skilled programmers to adapt the available data  to specific user needs. Bref we lack imagination, skills and perhaps political priority.

The whole data pricing problem can be regarded as a monopoly problem, classical and long.

----------------------------------------------------------------------------------------------

Proposal to the Freegis List.

As I stated earlier, to make metadata work we need to agree of identifiers for the normalizable objects...

The objects I am missing in a sense that would like to have a 'world wide ID ' for them are the following;

1.    dataprovider
2.    contact person
3.    several 'limited lists' (formats, software packages, languages, character sets, keywords etc)

To make these ids alive it seems obvious to me to make webservice, for example under freegis in which the details of these objects can be manipulated and searched.
Therefore I would like to know if anybody is interested in setting up such a service.

What is needed is a page to ingest and manipulate the data.
A service to extract the data per ID in an XML sheet
A service to search through the data.
Also needed are procedures to provoke that the providers and contact persons themselves help in keeping it all updated and probably a whole lot more that encompasses my perspective of the problem at this stage.

Arriverderci,

Alfred de Jager

-------------- next part --------------
A non-text attachment was scrubbed...
Name: alfred.de-jager.vcf
Type: text/x-vcard
Size: 578 bytes
Desc: Card for Alfred de Jager
Url : http://www.intevation.de/pipermail/freegis-list/attachments/20020404/c495c4f5/alfred.de-jager.vcf