Hi all,
a new beta is out.
Enjoy
Andrea
Hi guys,
I've been testing Geonetwork 2 Beta 3 and I would like to comment next points:
· z39.50 server works fine. In Geonetwork Beta 2 didn't work.
· I can't import metadata using the "Batch Import" option. I have 5 metadata files into a directory, and when I import this files I obtain next message: "<Import-ok>Records:5</Import-ok>". But then I can't find them using the search form. I think all these medatada aren't loaded in Geonetwork, because using the Beta 2 I do the same steps I can find the metadata. I can't continue testing the server if I can't load my data.
Best Regards!
--
Jorge Piera Llodra
Equipo de desarrollo gvSIG
Conselleria de Infraestructuras y Transporte
Generalitat Valenciana
Valencia - Spain
http://www.gvsig.gva.es
Thank you Roberto!
I've replaced the JAR file and I'm able to find my own metadata. I've have a look and I've seen one mistake. Maybe you have reported it but, I'm going to comment it
· I can't see the "Browse thumbnail button" until I enable the "fileType" option, that is not necessary to upload an image.
Good job!
Regards.
--
Jorge Piera Llodra
Equipo de desarrollo gvSIG
Conselleria de Infraestructuras y Transporte
Generalitat Valenciana
Valencia - Spain
http://www.gvsig.gva.es
Thank you Roberto!
I've replaced the JAR file and I'm able to find my own metadata. I've have a look and I've seen one mistake. Maybe you have reported it but, I'm going to comment it
· I can't see the "Browse thumbnail button" until I enable the "fileType" option, that is not necessary to upload an image.
Good job!
Regards.
--
Jorge Piera Llodra
Equipo de desarrollo gvSIG
Conselleria de Infraestructuras y Transporte
Generalitat Valenciana
Valencia - Spain
http://www.gvsig.gva.es
Hi Jorge!
First of all thanks for your useful contributions up to now! Today we will make a beta3.1 release to fix this and some other key problems we ran into and that are essential for the application to be useful at all.
I was just traveling to New York to UN Head Quarters (came back yesterday) and during the discussions it came to me that we would need an additional functionality that I think we may find in collaboration with your group.
What we would like to do is the following:
Use the Geonetwork harvesting capabilities already in place to schedule a scanning of a (local or remote) directory structure and scan the files in these directory folders. Using a library that is able to read out properties from files like shape files, coverages, image formats etc.. + maybe an existing metadata file in some format we could automatically generate or use an existing metadata that is inserted into GeoNetwork. Using a UUID and probably a node identifier we could than synchronize and update the metadata in the catalog with those data on the server. Probably also storing a metadata XML copy in the directory with the data where appropriate.
I understand you have developed an API / jar that is able to read properties from several data formats!? What would you think of adding such a capacity to GeoNetwork opensource? It wouldn't create high quality metadata in the first instance, but can be used as base records to be improved by the data owner at a later stage.
The next step than is to, besides having a quick updating of a local GIS data directory in the catalog (could include many other formats like spreadsheet and document types, GPS track logs etc..), also to have enough information to create / maintain Map Services on GeoServer and/or MapServer. By setting privileges on the metadata, services could be accessible from the web too (guess some more work is needed on the security 
).
Eventually the same kind of harvesting could be developed for GeoDatabases too.
Let me know what your ideas are on this (others may also have ideas!).
Greetings,
Jeroen
_______________________
Jeroen Ticheler
FAO-UN
Tel: +39 06 57056041
http://www.fao.org/geonetwork
Hi Jeroen,
I'm working with Jorge on his catalog client/metadata work side of
gvSIG, and it seems quite appealing your idea. But I'ld like to
structure it a little bit more.
Jeroen Ticheler wrote:
Hi Jorge!
First of all thanks for your useful contributions up to now! Today we will make a beta3.1 release to fix this and some other key problems we ran into and that are essential for the application to be useful at all.
Well, in our Free Software SDI solution your software it's a key
piece, due to the rol of broker betweend user and data that catalogs
must do. Yours it's the only no-OSG protocol that we've had to
'talk', and we'd like to improve the tool as much as needed for being
used in every context than a catalog server must be.
I was just traveling to New York to UN Head Quarters (came back yesterday) and during the discussions it came to me that we would need an additional functionality that I think we may find in collaboration with your group.
What we would like to do is the following:
Use the Geonetwork harvesting capabilities already in place to schedule a scanning of a (local or remote) directory structure and scan the files in these directory folders. Using a library that is able to read out properties from files like shape files, coverages, image formats etc.. + maybe an existing metadata file in some format we could automatically generate or use an existing metadata that is inserted into GeoNetwork. Using a UUID and probably a node identifier we could than synchronize and update the metadata in the catalog with those data on the server. Probably also storing a metadata XML copy in the directory with the data where appropriate.
It sounds more as a client feature than for the server itself.
GeoNetwork administering tool, or in our case our stand-alone GIS,
would enable a kind of batch self generated pre-load of metadata. But
as a catalog server would be in a production environment (as
FAO/geonetwork one), this, in my opinion, should be more a preparation
of a load than a load itself. The requirements of suitability for
searching ar far from being generated automatickly, so this new
generated metadata should be edited hevily before bein inserted on
catalog database.
I understand you have developed an API / jar that is able to read properties from several data formats!? What would you think of adding such a capacity to GeoNetwork opensource? It wouldn't create high quality metadata in the first instance, but can be used as base records to be improved by the data owner at a later stage.
on gvSIG we've developped a collection of data drivers than enable us
to load a not to wide range of geospatial data and services, and may
be used for the extraction of some data (as projection/crs/srs,
bounding box, pixel size, and others). I think Miguel Angel Manso,
from Mercator Group has some kind of complementary tool for this, and
he has done some bach generating metadata before. I'm contacting it
for enter on this thread 'cause automatic geretated metadata it's one
of his fields of study. Also Mike Gould, whos is heavily envolved in
metadata from long time ago as you know should give us a key point on
the right approach for this new development.
The next step than is to, besides having a quick updating of a local GIS data directory in the catalog (could include many other formats like spreadsheet and document types, GPS track logs etc..), also to have enough information to create / maintain Map Services on GeoServer and/or MapServer. By setting privileges on the metadata, services could be accessible from the web too (guess some more work is needed on the security
).
This will give us to a kind of data centered management tool for this
3 servers. It seems a killer idea, and deserves a good design work
before put us hands-on. For the whole SDI puzzle we need too gazeteer
server, than right now is a service that no one of us (server makers)
are announcing. Jorge has a working client for gazetteer both for ADL
and for WFS-G, and this service should be included in this services
management and metadata administering tool.
Eventually the same kind of harvesting could be developed for GeoDatabases too.
No doubt. Every GI available on an organization (or for public access)
should be metadatated, and an automatic aproach for this task it's
must.
Let me know what your ideas are on this (others may also have ideas!).
I had no wait for sending some small ideas about. I must mature the
concept and as I tell before structure it. I think on monday Jorge
will make his appointments, and I hope Mike and Miguel Angel would
like to tell something on this.
Greetings,
Jeroen
Good weekend
Luis
_______________________
Jeroen Ticheler
FAO-UN
Tel: +39 06 57056041
http://www.fao.org/geonetwork-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geonetwork-devel mailing list
Geonetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
gvSIG development team
www.gvsig.gva.es
Luis, Jeroen, all,
Yes indeed, we MUST semi-automate the MD collection process! This would
(will) be a big step forward. I am writing this development into all
possible proposals and we should get lucky with one of them...So in the near
term I expect to have one full-time person (in addition to Miguel Manso I
hope) working on it and I will feed him/her the ideas I have. Ideas such as
embedding content description (meta)data IN the data, and leaving discovery
metadata outside...
Also, have you read Gilberto Camara's geodata commons paper, where he
discusses a sort of interview-based metadata (invisible) creation process,
and also the idea of merging and inheriting metadata during data fusion?
Good ideas to contemplate.
http://www.dpi.inpe.br/gilberto/papers/commons_giscience2004.pdf
cheers,
-----------
Michael Gould
Department of Information Systems (LSI)
Universitat Jaume I, 12071 Castellón Spain
E-mail: gould (at) lsi.uji.es
http://www.mgould.com
http://www.geoinfo.uji.es
-----Mensaje original-----
De: Luis Sevilla [mailto:cresques@anonymised.com]
Enviado el: sábado, 24 de septiembre de 2005 21:01
Para: Jeroen Ticheler
CC: Jorge Piera; geonetwork-devel@lists.sourceforge.net; Michael Gould;
Miguel Angel Manso
Asunto: Re: [Geonetwork-devel] Metadata creation on the fly
Hi Jeroen,
I'm working with Jorge on his catalog client/metadata work side of
gvSIG, and it seems quite appealing your idea. But I'ld like to
structure it a little bit more.
Jeroen Ticheler wrote:
Hi Jorge!
First of all thanks for your useful contributions up to now! Today we
will make a beta3.1 release to fix this and some other key problems we ran
into and that are essential for the application to be useful at all.
Well, in our Free Software SDI solution your software it's a key
piece, due to the rol of broker betweend user and data that catalogs
must do. Yours it's the only no-OSG protocol that we've had to
'talk', and we'd like to improve the tool as much as needed for being
used in every context than a catalog server must be.
I was just traveling to New York to UN Head Quarters (came back
yesterday) and during the discussions it came to me that we would need an
additional functionality that I think we may find in collaboration with
your group.
What we would like to do is the following:
Use the Geonetwork harvesting capabilities already in place to schedule a
scanning of a (local or remote) directory structure and scan the files in
these directory folders. Using a library that is able to read out
properties from files like shape files, coverages, image formats etc.. +
maybe an existing metadata file in some format we could automatically
generate or use an existing metadata that is inserted into GeoNetwork.
Using a UUID and probably a node identifier we could than synchronize and
update the metadata in the catalog with those data on the server. Probably
also storing a metadata XML copy in the directory with the data where
appropriate.
It sounds more as a client feature than for the server itself.
GeoNetwork administering tool, or in our case our stand-alone GIS,
would enable a kind of batch self generated pre-load of metadata. But
as a catalog server would be in a production environment (as
FAO/geonetwork one), this, in my opinion, should be more a preparation
of a load than a load itself. The requirements of suitability for
searching ar far from being generated automatickly, so this new
generated metadata should be edited hevily before bein inserted on
catalog database.
I understand you have developed an API / jar that is able to read
properties from several data formats!? What would you think of adding such
a capacity to GeoNetwork opensource? It wouldn't create high quality
metadata in the first instance, but can be used as base records to be
improved by the data owner at a later stage.
on gvSIG we've developped a collection of data drivers than enable us
to load a not to wide range of geospatial data and services, and may
be used for the extraction of some data (as projection/crs/srs,
bounding box, pixel size, and others). I think Miguel Angel Manso,
from Mercator Group has some kind of complementary tool for this, and
he has done some bach generating metadata before. I'm contacting it
for enter on this thread 'cause automatic geretated metadata it's one
of his fields of study. Also Mike Gould, whos is heavily envolved in
metadata from long time ago as you know should give us a key point on
the right approach for this new development.
The next step than is to, besides having a quick updating of a local GIS
data directory in the catalog (could include many other formats like
spreadsheet and document types, GPS track logs etc..), also to have enough
information to create / maintain Map Services on GeoServer and/or
MapServer. By setting privileges on the metadata, services could be
accessible from the web too (guess some more work is needed on the security
).
This will give us to a kind of data centered management tool for this
3 servers. It seems a killer idea, and deserves a good design work
before put us hands-on. For the whole SDI puzzle we need too gazeteer
server, than right now is a service that no one of us (server makers)
are announcing. Jorge has a working client for gazetteer both for ADL
and for WFS-G, and this service should be included in this services
management and metadata administering tool.
Eventually the same kind of harvesting could be developed for
GeoDatabases too.
No doubt. Every GI available on an organization (or for public access)
should be metadatated, and an automatic aproach for this task it's
must.
Let me know what your ideas are on this (others may also have ideas!).
I had no wait for sending some small ideas about. I must mature the
concept and as I tell before structure it. I think on monday Jorge
will make his appointments, and I hope Mike and Miguel Angel would
like to tell something on this.
Greetings,
Jeroen
Good weekend
Luis
_______________________
Jeroen Ticheler
FAO-UN
Tel: +39 06 57056041
http://www.fao.org/geonetwork-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geonetwork-devel mailing list
Geonetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
gvSIG development team
www.gvsig.gva.es
No time to reply right now, but maybe we move this conversation to the
opensdi list? Since it's talking about the sorts of links between open
source projects that we started that for, and indeed the single server
to administer sdi stuff.
Quoting Luis Sevilla <cresques@anonymised.com>:
Hi Jeroen,
I'm working with Jorge on his catalog client/metadata work side of
gvSIG, and it seems quite appealing your idea. But I'ld like to
structure it a little bit more.
Jeroen Ticheler wrote:> Hi Jorge!
> First of all thanks for your useful contributions up to now! Today
we will make a beta3.1 release to fix this and some other key
problems we ran into and that are essential for the application to
be useful at all.Well, in our Free Software SDI solution your software it's a key
piece, due to the rol of broker betweend user and data that
catalogs
must do. Yours it's the only no-OSG protocol that we've had to
'talk', and we'd like to improve the tool as much as needed for being
used in every context than a catalog server must be.> I was just traveling to New York to UN Head Quarters (came back
yesterday) and during the discussions it came to me that we would
need an additional functionality that I think we may find in
collaboration with your group.
>
> What we would like to do is the following:
>
> Use the Geonetwork harvesting capabilities already in place to
schedule a scanning of a (local or remote) directory structure and
scan the files in these directory folders. Using a library that is
able to read out properties from files like shape files, coverages,
image formats etc.. + maybe an existing metadata file in some format
we could automatically generate or use an existing metadata that is
inserted into GeoNetwork. Using a UUID and probably a node identifier
we could than synchronize and update the metadata in the catalog
with those data on the server. Probably also storing a metadata XML
copy in the directory with the data where appropriate.It sounds more as a client feature than for the server itself.
GeoNetwork administering tool, or in our case our stand-alone GIS,
would enable a kind of batch self generated pre-load of metadata. But
as a catalog server would be in a production environment (as
FAO/geonetwork one), this, in my opinion, should be more a
preparation
of a load than a load itself. The requirements of suitability for
searching ar far from being generated automatickly, so this new
generated metadata should be edited hevily before bein inserted on
catalog database.> I understand you have developed an API / jar that is able to read
properties from several data formats!? What would you think of adding
such a capacity to GeoNetwork opensource? It wouldn't create high
quality metadata in the first instance, but can be used as base
records to be improved by the data owner at a later stage.on gvSIG we've developped a collection of data drivers than enable
us
to load a not to wide range of geospatial data and services, and may
be used for the extraction of some data (as projection/crs/srs,
bounding box, pixel size, and others). I think Miguel Angel Manso,
from Mercator Group has some kind of complementary tool for this, and
he has done some bach generating metadata before. I'm contacting it
for enter on this thread 'cause automatic geretated metadata it's one
of his fields of study. Also Mike Gould, whos is heavily envolved in
metadata from long time ago as you know should give us a key point on
the right approach for this new development.> The next step than is to, besides having a quick updating of a
local GIS data directory in the catalog (could include many other
formats like spreadsheet and document types, GPS track logs etc..),
also to have enough information to create / maintain Map Services on
GeoServer and/or MapServer. By setting privileges on the metadata,
services could be accessible from the web too (guess some more work
is needed on the securityThis will give us to a kind of data centered management tool for
this
3 servers. It seems a killer idea, and deserves a good design work
before put us hands-on. For the whole SDI puzzle we need too gazeteer
server, than right now is a service that no one of us (server makers)
are announcing. Jorge has a working client for gazetteer both for ADL
and for WFS-G, and this service should be included in this services
management and metadata administering tool.> Eventually the same kind of harvesting could be developed for
GeoDatabases too.No doubt. Every GI available on an organization (or for public
access)
should be metadatated, and an automatic aproach for this task it's
must.> Let me know what your ideas are on this (others may also have
ideas!).I had no wait for sending some small ideas about. I must mature the
concept and as I tell before structure it. I think on monday Jorge
will make his appointments, and I hope Mike and Miguel Angel would
like to tell something on this.> Greetings,
> JeroenGood weekend
Luis
> _______________________
> Jeroen Ticheler
> FAO-UN
> Tel: +39 06 57056041
> http://www.fao.org/geonetwork
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very
> own Sony(tm)PSP. Click here to play:
http://sourceforge.net/geronimo.php
> _______________________________________________
> Geonetwork-devel mailing list
> Geonetwork-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
>
gvSIG development team
www.gvsig.gva.es-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very
own Sony(tm)PSP. Click here to play:
http://sourceforge.net/geronimo.php
_______________________________________________
Geonetwork-devel mailing list
Geonetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
Check out this site
http://www.albinoblacksheep.com/flash/epic
-----------
Michael Gould
Department of Information Systems (LSI)
Universitat Jaume I, 12071 Castellón Spain
E-mail: gould (at) lsi.uji.es
http://www.mgould.com
http://www.geoinfo.uji.es
-----Mensaje original-----
De: Chris Holmes [mailto:cholmes@anonymised.com]
Enviado el: domingo, 25 de septiembre de 2005 16:30
Para: Luis Sevilla
CC: Jeroen Ticheler; dblasby@anonymised.com; Jorge Piera;
geonetwork-devel@lists.sourceforge.net; Michael Gould; Miguel Angel Manso
Asunto: Re: [Geonetwork-devel] Metadata creation on the fly
No time to reply right now, but maybe we move this conversation to the
opensdi list? Since it's talking about the sorts of links between open
source projects that we started that for, and indeed the single server
to administer sdi stuff.
Quoting Luis Sevilla <cresques@anonymised.com>:
Hi Jeroen,
I'm working with Jorge on his catalog client/metadata work side of
gvSIG, and it seems quite appealing your idea. But I'ld like to
structure it a little bit more.
Jeroen Ticheler wrote:> Hi Jorge!
> First of all thanks for your useful contributions up to now! Today
we will make a beta3.1 release to fix this and some other key
problems we ran into and that are essential for the application to
be useful at all.Well, in our Free Software SDI solution your software it's a key
piece, due to the rol of broker betweend user and data that
catalogs
must do. Yours it's the only no-OSG protocol that we've had to
'talk', and we'd like to improve the tool as much as needed for being
used in every context than a catalog server must be.> I was just traveling to New York to UN Head Quarters (came back
yesterday) and during the discussions it came to me that we would
need an additional functionality that I think we may find in
collaboration with your group.
>
> What we would like to do is the following:
>
> Use the Geonetwork harvesting capabilities already in place to
schedule a scanning of a (local or remote) directory structure and
scan the files in these directory folders. Using a library that is
able to read out properties from files like shape files, coverages,
image formats etc.. + maybe an existing metadata file in some format
we could automatically generate or use an existing metadata that is
inserted into GeoNetwork. Using a UUID and probably a node identifier
we could than synchronize and update the metadata in the catalog
with those data on the server. Probably also storing a metadata XML
copy in the directory with the data where appropriate.It sounds more as a client feature than for the server itself.
GeoNetwork administering tool, or in our case our stand-alone GIS,
would enable a kind of batch self generated pre-load of metadata. But
as a catalog server would be in a production environment (as
FAO/geonetwork one), this, in my opinion, should be more a
preparation
of a load than a load itself. The requirements of suitability for
searching ar far from being generated automatickly, so this new
generated metadata should be edited hevily before bein inserted on
catalog database.> I understand you have developed an API / jar that is able to read
properties from several data formats!? What would you think of adding
such a capacity to GeoNetwork opensource? It wouldn't create high
quality metadata in the first instance, but can be used as base
records to be improved by the data owner at a later stage.on gvSIG we've developped a collection of data drivers than enable
us
to load a not to wide range of geospatial data and services, and may
be used for the extraction of some data (as projection/crs/srs,
bounding box, pixel size, and others). I think Miguel Angel Manso,
from Mercator Group has some kind of complementary tool for this, and
he has done some bach generating metadata before. I'm contacting it
for enter on this thread 'cause automatic geretated metadata it's one
of his fields of study. Also Mike Gould, whos is heavily envolved in
metadata from long time ago as you know should give us a key point on
the right approach for this new development.> The next step than is to, besides having a quick updating of a
local GIS data directory in the catalog (could include many other
formats like spreadsheet and document types, GPS track logs etc..),
also to have enough information to create / maintain Map Services on
GeoServer and/or MapServer. By setting privileges on the metadata,
services could be accessible from the web too (guess some more work
is needed on the securityThis will give us to a kind of data centered management tool for
this
3 servers. It seems a killer idea, and deserves a good design work
before put us hands-on. For the whole SDI puzzle we need too gazeteer
server, than right now is a service that no one of us (server makers)
are announcing. Jorge has a working client for gazetteer both for ADL
and for WFS-G, and this service should be included in this services
management and metadata administering tool.> Eventually the same kind of harvesting could be developed for
GeoDatabases too.No doubt. Every GI available on an organization (or for public
access)
should be metadatated, and an automatic aproach for this task it's
must.> Let me know what your ideas are on this (others may also have
ideas!).I had no wait for sending some small ideas about. I must mature the
concept and as I tell before structure it. I think on monday Jorge
will make his appointments, and I hope Mike and Miguel Angel would
like to tell something on this.> Greetings,
> JeroenGood weekend
Luis
> _______________________
> Jeroen Ticheler
> FAO-UN
> Tel: +39 06 57056041
> http://www.fao.org/geonetwork
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very
> own Sony(tm)PSP. Click here to play:
http://sourceforge.net/geronimo.php
> _______________________________________________
> Geonetwork-devel mailing list
> Geonetwork-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
> GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
>
gvSIG development team
www.gvsig.gva.es-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very
own Sony(tm)PSP. Click here to play:
http://sourceforge.net/geronimo.php
_______________________________________________
Geonetwork-devel mailing list
Geonetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
As suggested by Chris, let me move/copy this discussion to the OpenSDI list as well as I feel it touches with the GDAL Java bindings discussion there too.
I'll put up an idea that may be (it actually is) absolutely ignorant of what the Java bindings to GDAL actually are , but link the two topics discussed in some way.
What if the GDAL/OGR utilities gdalinfo and ogrinfo would be used to generate part of the metadata automatically? They can deal with a great number of formats and would provide essential information for both a catalog as well as for the creation of map services on GeoServer and MapServer as discussed below. A scheduled process can scan the directory structure and generate the necessary information in an ISO19115 formatted XML file (updating an existing one, creating a new one when none exists).
The only "worry" would be the mixing of java and C technologies that require specific installers for the different platforms, but as a "feature" to enable automatic metadata generation it may be a solution!?
Ciao,
Jeroen
On 25 Sep 2005, at 01:08, michael gould wrote:
Luis, Jeroen, all,
Yes indeed, we MUST semi-automate the MD collection process! This would
(will) be a big step forward. I am writing this development into all
possible proposals and we should get lucky with one of them...So in the near
term I expect to have one full-time person (in addition to Miguel Manso I
hope) working on it and I will feed him/her the ideas I have. Ideas such as
embedding content description (meta)data IN the data, and leaving discovery
metadata outside...Also, have you read Gilberto Camara's geodata commons paper, where he
discusses a sort of interview-based metadata (invisible) creation process,
and also the idea of merging and inheriting metadata during data fusion?
Good ideas to contemplate.http://www.dpi.inpe.br/gilberto/papers/commons_giscience2004.pdf
cheers,
-----------
Michael Gould
Department of Information Systems (LSI)
Universitat Jaume I, 12071 Castellón Spain
E-mail: gould (at) lsi.uji.es
http://www.mgould.com
http://www.geoinfo.uji.es-----Mensaje original-----
De: Luis Sevilla [mailto:cresques@anonymised.com]
Enviado el: sábado, 24 de septiembre de 2005 21:01
Para: Jeroen Ticheler
CC: Jorge Piera; geonetwork-devel@lists.sourceforge.net; Michael Gould;
Miguel Angel Manso
Asunto: Re: [Geonetwork-devel] Metadata creation on the flyHi Jeroen,
I'm working with Jorge on his catalog client/metadata work side of
gvSIG, and it seems quite appealing your idea. But I'ld like to
structure it a little bit more.
Jeroen Ticheler wrote:Hi Jorge!
First of all thanks for your useful contributions up to now! Today wewill make a beta3.1 release to fix this and some other key problems we ran
into and that are essential for the application to be useful at all.Well, in our Free Software SDI solution your software it's a key
piece, due to the rol of broker betweend user and data that catalogs
must do. Yours it's the only no-OSG protocol that we've had to
'talk', and we'd like to improve the tool as much as needed for being
used in every context than a catalog server must be.I was just traveling to New York to UN Head Quarters (came back
yesterday) and during the discussions it came to me that we would need an
additional functionality that I think we may find in collaboration with
your group.What we would like to do is the following:
Use the Geonetwork harvesting capabilities already in place to schedule a
scanning of a (local or remote) directory structure and scan the files in
these directory folders. Using a library that is able to read out
properties from files like shape files, coverages, image formats etc.. +
maybe an existing metadata file in some format we could automatically
generate or use an existing metadata that is inserted into GeoNetwork.
Using a UUID and probably a node identifier we could than synchronize and
update the metadata in the catalog with those data on the server. Probably
also storing a metadata XML copy in the directory with the data where
appropriate.It sounds more as a client feature than for the server itself.
GeoNetwork administering tool, or in our case our stand-alone GIS,
would enable a kind of batch self generated pre-load of metadata. But
as a catalog server would be in a production environment (as
FAO/geonetwork one), this, in my opinion, should be more a preparation
of a load than a load itself. The requirements of suitability for
searching ar far from being generated automatickly, so this new
generated metadata should be edited hevily before bein inserted on
catalog database.I understand you have developed an API / jar that is able to read
properties from several data formats!? What would you think of adding such
a capacity to GeoNetwork opensource? It wouldn't create high quality
metadata in the first instance, but can be used as base records to be
improved by the data owner at a later stage.on gvSIG we've developped a collection of data drivers than enable us
to load a not to wide range of geospatial data and services, and may
be used for the extraction of some data (as projection/crs/srs,
bounding box, pixel size, and others). I think Miguel Angel Manso,
from Mercator Group has some kind of complementary tool for this, and
he has done some bach generating metadata before. I'm contacting it
for enter on this thread 'cause automatic geretated metadata it's one
of his fields of study. Also Mike Gould, whos is heavily envolved in
metadata from long time ago as you know should give us a key point on
the right approach for this new development.The next step than is to, besides having a quick updating of a local GIS
data directory in the catalog (could include many other formats like
spreadsheet and document types, GPS track logs etc..), also to have enough
information to create / maintain Map Services on GeoServer and/or
MapServer. By setting privileges on the metadata, services could be
accessible from the web too (guess some more work is needed on the security
This will give us to a kind of data centered management tool for this
3 servers. It seems a killer idea, and deserves a good design work
before put us hands-on. For the whole SDI puzzle we need too gazeteer
server, than right now is a service that no one of us (server makers)
are announcing. Jorge has a working client for gazetteer both for ADL
and for WFS-G, and this service should be included in this services
management and metadata administering tool.Eventually the same kind of harvesting could be developed for
GeoDatabases too.
No doubt. Every GI available on an organization (or for public access)
should be metadatated, and an automatic aproach for this task it's
must.Let me know what your ideas are on this (others may also have ideas!).
I had no wait for sending some small ideas about. I must mature the
concept and as I tell before structure it. I think on monday Jorge
will make his appointments, and I hope Mike and Miguel Angel would
like to tell something on this.Greetings,
JeroenGood weekend
Luis
_______________________
Jeroen Ticheler
FAO-UN
Tel: +39 06 57056041
FAO Map Catalog-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geonetwork-devel mailing list
Geonetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained athttp://sourceforge.net/projects/geonetwork
gvSIG development team
www.gvsig.gva.es-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geonetwork-devel mailing list
Geonetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
As suggested by Chris, let me move/copy this discussion to the OpenSDI list as well as I feel it touches with the GDAL Java bindings discussion there too.
I'll put up an idea that may be (it actually is) absolutely ignorant of what the Java bindings to GDAL actually are , but link the two topics discussed in some way.
What if the GDAL/OGR utilities gdalinfo and ogrinfo would be used to generate part of the metadata automatically? They can deal with a great number of formats and would provide essential information for both a catalog as well as for the creation of map services on GeoServer and MapServer as discussed below. A scheduled process can scan the directory structure and generate the necessary information in an ISO19115 formatted XML file (updating an existing one, creating a new one when none exists).
The only "worry" would be the mixing of java and C technologies that require specific installers for the different platforms, but as a "feature" to enable automatic metadata generation it may be a solution!?
Ciao,
Jeroen
On 25 Sep 2005, at 01:08, michael gould wrote:
Luis, Jeroen, all,
Yes indeed, we MUST semi-automate the MD collection process! This would
(will) be a big step forward. I am writing this development into all
possible proposals and we should get lucky with one of them...So in the near
term I expect to have one full-time person (in addition to Miguel Manso I
hope) working on it and I will feed him/her the ideas I have. Ideas such as
embedding content description (meta)data IN the data, and leaving discovery
metadata outside...Also, have you read Gilberto Camara's geodata commons paper, where he
discusses a sort of interview-based metadata (invisible) creation process,
and also the idea of merging and inheriting metadata during data fusion?
Good ideas to contemplate.http://www.dpi.inpe.br/gilberto/papers/commons_giscience2004.pdf
cheers,
-----------
Michael Gould
Department of Information Systems (LSI)
Universitat Jaume I, 12071 Castellón Spain
E-mail: gould (at) lsi.uji.es
http://www.mgould.com
http://www.geoinfo.uji.es-----Mensaje original-----
De: Luis Sevilla [mailto:cresques@anonymised.com]
Enviado el: sábado, 24 de septiembre de 2005 21:01
Para: Jeroen Ticheler
CC: Jorge Piera; geonetwork-devel@lists.sourceforge.net; Michael Gould;
Miguel Angel Manso
Asunto: Re: [Geonetwork-devel] Metadata creation on the flyHi Jeroen,
I'm working with Jorge on his catalog client/metadata work side of
gvSIG, and it seems quite appealing your idea. But I'ld like to
structure it a little bit more.
Jeroen Ticheler wrote:Hi Jorge!
First of all thanks for your useful contributions up to now! Today wewill make a beta3.1 release to fix this and some other key problems we ran
into and that are essential for the application to be useful at all.Well, in our Free Software SDI solution your software it's a key
piece, due to the rol of broker betweend user and data that catalogs
must do. Yours it's the only no-OSG protocol that we've had to
'talk', and we'd like to improve the tool as much as needed for being
used in every context than a catalog server must be.I was just traveling to New York to UN Head Quarters (came back
yesterday) and during the discussions it came to me that we would need an
additional functionality that I think we may find in collaboration with
your group.What we would like to do is the following:
Use the Geonetwork harvesting capabilities already in place to schedule a
scanning of a (local or remote) directory structure and scan the files in
these directory folders. Using a library that is able to read out
properties from files like shape files, coverages, image formats etc.. +
maybe an existing metadata file in some format we could automatically
generate or use an existing metadata that is inserted into GeoNetwork.
Using a UUID and probably a node identifier we could than synchronize and
update the metadata in the catalog with those data on the server. Probably
also storing a metadata XML copy in the directory with the data where
appropriate.It sounds more as a client feature than for the server itself.
GeoNetwork administering tool, or in our case our stand-alone GIS,
would enable a kind of batch self generated pre-load of metadata. But
as a catalog server would be in a production environment (as
FAO/geonetwork one), this, in my opinion, should be more a preparation
of a load than a load itself. The requirements of suitability for
searching ar far from being generated automatickly, so this new
generated metadata should be edited hevily before bein inserted on
catalog database.I understand you have developed an API / jar that is able to read
properties from several data formats!? What would you think of adding such
a capacity to GeoNetwork opensource? It wouldn't create high quality
metadata in the first instance, but can be used as base records to be
improved by the data owner at a later stage.on gvSIG we've developped a collection of data drivers than enable us
to load a not to wide range of geospatial data and services, and may
be used for the extraction of some data (as projection/crs/srs,
bounding box, pixel size, and others). I think Miguel Angel Manso,
from Mercator Group has some kind of complementary tool for this, and
he has done some bach generating metadata before. I'm contacting it
for enter on this thread 'cause automatic geretated metadata it's one
of his fields of study. Also Mike Gould, whos is heavily envolved in
metadata from long time ago as you know should give us a key point on
the right approach for this new development.The next step than is to, besides having a quick updating of a local GIS
data directory in the catalog (could include many other formats like
spreadsheet and document types, GPS track logs etc..), also to have enough
information to create / maintain Map Services on GeoServer and/or
MapServer. By setting privileges on the metadata, services could be
accessible from the web too (guess some more work is needed on the security
This will give us to a kind of data centered management tool for this
3 servers. It seems a killer idea, and deserves a good design work
before put us hands-on. For the whole SDI puzzle we need too gazeteer
server, than right now is a service that no one of us (server makers)
are announcing. Jorge has a working client for gazetteer both for ADL
and for WFS-G, and this service should be included in this services
management and metadata administering tool.Eventually the same kind of harvesting could be developed for
GeoDatabases too.
No doubt. Every GI available on an organization (or for public access)
should be metadatated, and an automatic aproach for this task it's
must.Let me know what your ideas are on this (others may also have ideas!).
I had no wait for sending some small ideas about. I must mature the
concept and as I tell before structure it. I think on monday Jorge
will make his appointments, and I hope Mike and Miguel Angel would
like to tell something on this.Greetings,
JeroenGood weekend
Luis
_______________________
Jeroen Ticheler
FAO-UN
Tel: +39 06 57056041
FAO Map Catalog-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geonetwork-devel mailing list
Geonetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained athttp://sourceforge.net/projects/geonetwork
gvSIG development team
www.gvsig.gva.es-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geonetwork-devel mailing list
Geonetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
Jeroen Ticheler wrote:
As suggested by Chris, let me move/copy this discussion to the OpenSDI list as well as I feel it touches with the GDAL Java bindings discussion there too.
I'll put up an idea that may be (it actually is) absolutely ignorant of what the Java bindings to GDAL actually are
What if the GDAL/OGR utilities gdalinfo and ogrinfo would be used to generate part of the metadata automatically? They can deal with a great number of formats and would provide essential information for both a catalog as well as for the creation of map services on GeoServer and MapServer as discussed below. A scheduled process can scan the directory structure and generate the necessary information in an ISO19115 formatted XML file (updating an existing one, creating a new one when none exists).
Yes, this is a right assesment, but my concerns are that the main part of metadata isn't on the files, and on all your drafts of the metadata harvesting you seemed to ignore this aspect. Technical medatada authomatic extraction from file and services it's the lesser part of metadata creation, and also it's the less conflicting ones.
It seemed to me than this harvest was more the start of a kind od 'metadata creation wizard', than a creator one.
For creation of services MapServices seem more suited, but again this seem to me the lesser of the problems (maybe for my ignorance or for a a selfish looking to the problem). Administering of map services publication on our project it's a really challenging task, due to the amount of info being served, and the variety of formats. The search of optimization for this servers setups takes a lot of time, and havind a kind of 'geoervices central adminstration' would became, surely, the key feature for an 'easy of deploy' FOSS SDI.
But, on my thinking, both this GeoServices central admistration service, and the semi-authomatic metadata creation need a good definition as a problem, before of thinking of doing a prototype (or even proof of concept) implementation
The only "worry" would be the mixing of java and C technologies that require specific installers for the different platforms, but as a "feature" to enable automatic metadata generation it may be a solution!?
Well, I think this worry may be an answer seeing our binary distribution, boths for windows and linux. For sources, you may need only to fight against java, and use jCMS for using those C/C++ libraries. The delivery of JNI sources was mainly for maintaining the free code filosophy, and to receive some feedback and help on completing the work, but usualy they needn't be recompiled.
Ciao,
Jeroen
Greetings
Luis
On 25 Sep 2005, at 01:08, michael gould wrote:
Luis, Jeroen, all,
Yes indeed, we MUST semi-automate the MD collection process! This would
(will) be a big step forward. I am writing this development into all
possible proposals and we should get lucky with one of them...So in the near
term I expect to have one full-time person (in addition to Miguel Manso I
hope) working on it and I will feed him/her the ideas I have. Ideas such as
embedding content description (meta)data IN the data, and leaving discovery
metadata outside...Also, have you read Gilberto Camara's geodata commons paper, where he
discusses a sort of interview-based metadata (invisible) creation process,
and also the idea of merging and inheriting metadata during data fusion?
Good ideas to contemplate.http://www.dpi.inpe.br/gilberto/papers/commons_giscience2004.pdf
cheers,
-----------
Michael Gould
Department of Information Systems (LSI)
Universitat Jaume I, 12071 Castellón Spain
E-mail: gould (at) lsi.uji.es
http://www.mgould.com
http://www.geoinfo.uji.es-----Mensaje original-----
De: Luis Sevilla [mailto:cresques@anonymised.com]
Enviado el: sábado, 24 de septiembre de 2005 21:01
Para: Jeroen Ticheler
CC: Jorge Piera; geonetwork-devel@lists.sourceforge.net; Michael Gould;
Miguel Angel Manso
Asunto: Re: [Geonetwork-devel] Metadata creation on the flyHi Jeroen,
I'm working with Jorge on his catalog client/metadata work side of
gvSIG, and it seems quite appealing your idea. But I'ld like to
structure it a little bit more.
Jeroen Ticheler wrote:Hi Jorge!
First of all thanks for your useful contributions up to now! Today wewill make a beta3.1 release to fix this and some other key problems we ran
into and that are essential for the application to be useful at all.Well, in our Free Software SDI solution your software it's a key
piece, due to the rol of broker betweend user and data that catalogs
must do. Yours it's the only no-OSG protocol that we've had to
'talk', and we'd like to improve the tool as much as needed for being
used in every context than a catalog server must be.I was just traveling to New York to UN Head Quarters (came back
yesterday) and during the discussions it came to me that we would need an
additional functionality that I think we may find in collaboration with
your group.What we would like to do is the following:
Use the Geonetwork harvesting capabilities already in place to schedule a
scanning of a (local or remote) directory structure and scan the files in
these directory folders. Using a library that is able to read out
properties from files like shape files, coverages, image formats etc.. +
maybe an existing metadata file in some format we could automatically
generate or use an existing metadata that is inserted into GeoNetwork.
Using a UUID and probably a node identifier we could than synchronize and
update the metadata in the catalog with those data on the server. Probably
also storing a metadata XML copy in the directory with the data where
appropriate.It sounds more as a client feature than for the server itself.
GeoNetwork administering tool, or in our case our stand-alone GIS,
would enable a kind of batch self generated pre-load of metadata. But
as a catalog server would be in a production environment (as
FAO/geonetwork one), this, in my opinion, should be more a preparation
of a load than a load itself. The requirements of suitability for
searching ar far from being generated automatickly, so this new
generated metadata should be edited hevily before bein inserted on
catalog database.I understand you have developed an API / jar that is able to read
properties from several data formats!? What would you think of adding such
a capacity to GeoNetwork opensource? It wouldn't create high quality
metadata in the first instance, but can be used as base records to be
improved by the data owner at a later stage.on gvSIG we've developped a collection of data drivers than enable us
to load a not to wide range of geospatial data and services, and may
be used for the extraction of some data (as projection/crs/srs,
bounding box, pixel size, and others). I think Miguel Angel Manso,
from Mercator Group has some kind of complementary tool for this, and
he has done some bach generating metadata before. I'm contacting it
for enter on this thread 'cause automatic geretated metadata it's one
of his fields of study. Also Mike Gould, whos is heavily envolved in
metadata from long time ago as you know should give us a key point on
the right approach for this new development.The next step than is to, besides having a quick updating of a local GIS
data directory in the catalog (could include many other formats like
spreadsheet and document types, GPS track logs etc..), also to have enough
information to create / maintain Map Services on GeoServer and/or
MapServer. By setting privileges on the metadata, services could be
accessible from the web too (guess some more work is needed on the security
This will give us to a kind of data centered management tool for this
3 servers. It seems a killer idea, and deserves a good design work
before put us hands-on. For the whole SDI puzzle we need too gazeteer
server, than right now is a service that no one of us (server makers)
are announcing. Jorge has a working client for gazetteer both for ADL
and for WFS-G, and this service should be included in this services
management and metadata administering tool.Eventually the same kind of harvesting could be developed for
GeoDatabases too.
No doubt. Every GI available on an organization (or for public access)
should be metadatated, and an automatic aproach for this task it's
must.Let me know what your ideas are on this (others may also have ideas!).
I had no wait for sending some small ideas about. I must mature the
concept and as I tell before structure it. I think on monday Jorge
will make his appointments, and I hope Mike and Miguel Angel would
like to tell something on this.Greetings,
JeroenGood weekend
Luis
_______________________
Jeroen Ticheler
FAO-UN
Tel: +39 06 57056041
http://www.fao.org/geonetwork-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/ geronimo.php
_______________________________________________
Geonetwork-devel mailing list
Geonetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained athttp://sourceforge.net/projects/geonetwork
gvSIG development team
www.gvsig.gva.es-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/ geronimo.php
_______________________________________________
Geonetwork-devel mailing list
Geonetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/ projects/geonetwork_______________________________________________
OpenSDI mailing list
OpenSDI@anonymised.com
http://lists.eogeo.org/mailman/listinfo/opensdi
--
Luis W. Sevilla
gvSIG development team
Conselleria de Infraestructuras y Transporte
Generalitat Valenciana
Valencia - Spain
http://www.gvsig.gva.es
Hi Luis,
Yes, this is a right assesment, but my concerns are that the main part of metadata isn't on the files, and on all your drafts of the metadata harvesting you seemed to ignore this aspect. Technical medatada authomatic extraction from file and services it's the lesser part of metadata creation, and also it's the less conflicting ones.
It seemed to me than this harvest was more the start of a kind od 'metadata creation wizard', than a creator one.
In fact it is, let me give you some more background on the use of this;
Spatial data comes in very rapidly after a major disaster and needs to be catalogued in such a way that it requires the minimal time as possible in the early stages of the start of an emergency relief operation. Many versions of the same data may come in and data are updated frequently changing some of its data properties. At the same time it is critical that there is some kind of structure in how these data can be found again by others involved in the relief operations. At a later stage, when time permits, more time ca be taken to update the catalogued metadata. At that point it can also be decided more carefully what data to publish and what not on e.g. the internet.
The data will be first catalogued in a set directory structure (this is how they work already).
My idea is that we would use the template functionality GeoNetwork and an additional text file and/or fixed directory structure to generate a metadata record based on one of the templates, the information on the data set itself (including time of update) and the information as extracted from the text file (or another form of minimal metadata file with e.g. title, abstract and source) and with the directory structure. Someone coming in to deliver new data is required to fill out a minimum of metadata creating the file mentioned before. Such a form should not have more than two to four fields, otherwise it will just take too much time at first.
For creation of services MapServices seem more suited, but again this seem to me the lesser of the problems (maybe for my ignorance or for a a selfish looking to the problem). Administering of map services publication on our project it's a really challenging task, due to the amount of info being served, and the variety of formats. The search of optimization for this servers setups takes a lot of time, and havind a kind of 'geoervices central adminstration' would became, surely, the key feature for an 'easy of deploy' FOSS SDI.
Agreed. It would be great to see those server use metadata for their configuration. At the same time they could update their status in the metadata record so a user can see if the service is actually up and running for instance.
But, on my thinking, both this GeoServices central admistration service, and the semi-authomatic metadata creation need a good definition as a problem, before of thinking of doing a prototype (or even proof of concept) implementation
Yes, hope this discussion helps in defining the problem related to the semi-automated creation of metadata at least.
Ciao,
Jeroen
Jeroen Ticheler wrote:
Hi Luis,
Yes, this is a right assesment, but my concerns are that the main part of metadata isn't on the files, and on all your drafts of the metadata harvesting you seemed to ignore this aspect. Technical medatada authomatic extraction from file and services it's the lesser part of metadata creation, and also it's the less conflicting ones.
It seemed to me than this harvest was more the start of a kind od 'metadata creation wizard', than a creator one.In fact it is, let me give you some more background on the use of this;
Spatial data comes in very rapidly after a major disaster and needs to be catalogued in such a way that it requires the minimal time as possible in the early stages of the start of an emergency relief operation. Many versions of the same data may come in and data are updated frequently changing some of its data properties. At the same time it is critical that there is some kind of structure in how these data can be found again by others involved in the relief operations. At a later stage, when time permits, more time ca be taken to update the catalogued metadata. At that point it can also be decided more carefully what data to publish and what not on e.g. the internet.
The data will be first catalogued in a set directory structure (this is how they work already).My idea is that we would use the template functionality GeoNetwork and an additional text file and/or fixed directory structure to generate a metadata record based on one of the templates, the information on the data set itself (including time of update) and the information as extracted from the text file (or another form of minimal metadata file with e.g. title, abstract and source) and with the directory structure. Someone coming in to deliver new data is required to fill out a minimum of metadata creating the file mentioned before. Such a form should not have more than two to four fields, otherwise it will just take too much time at first.
Now I think I'm getting your point. With this use case as an intial target we can design not a general metadata harvesting tool, but a more specific one, in a kind a 'controlled environment', that may prove the strenghts and weaknesses of this idea. Shoudn't it be too dificult to draft an scenario as testbed (simulating this big amount of data coming oftenly), and build up a prototype on top for polishing the idea.
For creation of services MapServices seem more suited, but again this seem to me the lesser of the problems (maybe for my ignorance or for a a selfish looking to the problem). Administering of map services publication on our project it's a really challenging task, due to the amount of info being served, and the variety of formats. The search of optimization for this servers setups takes a lot of time, and havind a kind of 'geoervices central adminstration' would became, surely, the key feature for an 'easy of deploy' FOSS SDI.
Agreed. It would be great to see those server use metadata for their configuration. At the same time they could update their status in the metadata record so a user can see if the service is actually up and running for instance.
But, on my thinking, both this GeoServices central admistration service, and the semi-authomatic metadata creation need a good definition as a problem, before of thinking of doing a prototype (or even proof of concept) implementation
Yes, hope this discussion helps in defining the problem related to the semi-automated creation of metadata at least.
I'm pretty sure it'll do. Let's work the idea and start designing and implementing.
Ciao,
Jeroen
Saludos
Luis
--
Luis W. Sevilla
Equipo de desarrollo gvSIG
Conselleria de Infraestructuras y Transporte
Generalitat Valenciana
Valencia - Spain
http://www.gvsig.gva.es