<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Armin,<br>
<br>
find (short) comments inline.<br>
<br>
<br>
On 05.08.2010 12:09, Armin Retterath wrote:
<blockquote
cite="mid:201008051209.47495.armin.retterath@lvermgeo.rlp.de"
type="cite">
<pre wrap="">hello list,
we plan to integrate some new features in mapbender trunk.
1. possibility to register dataurls for resources like newsfeed and kml files
2. a possibility to define some kind of auto update function for the managed
services and urls
1) in the next version of mapbender, there will be a possibility to have a
layertree for georss and kml objects which can be dynamically added to the
mapbender client (per http-get). in our application we want to give a
possibility for the decentral organizations to register the urls to those
resources in the mapbender database. the resources can be searched thru the
searchinterface and can dynamically integrated in the mapbender application.
for supporting the search we want to give some classifications and keywords to
the resources. this is similar to the register process for the wms and wfs and
is somehow comparable to generating a metadata record with a link to a dataset
- but easier to understand ;-) . beside of registrating the url, maybe some
institutions want to upload a kml or gml file cause the have no webserver to
publish it. the data will be stored in the column datalink_data and mapbender
will serve it to the web!
</pre>
</blockquote>
<br>
A very(!) cool idea. <br>
<ul>
<li>Will there be some (syntax-)validation going on?</li>
<li>Which outputformats do you have in mind? </li>
<li>Will it be possible to upload geojson and publish it as GML? </li>
<li>If so, will these ressources be RESTful?<br>
e.g. GET <a class="moz-txt-link-freetext" href="http://example.com/mapbender/datalink/42/KML">http://example.com/mapbender/datalink/42/KML</a><br>
or GET <a class="moz-txt-link-freetext" href="http://example.com/mapbender/datalink/42/geojson">http://example.com/mapbender/datalink/42/geojson</a> (doesn't care
in which format it was once uploaded)<br>
</li>
</ul>
<br>
<blockquote
cite="mid:201008051209.47495.armin.retterath@lvermgeo.rlp.de"
type="cite">
<pre wrap="">here is the draft of the database changes (with a rfc):
-- Table: datalink
-- DROP TABLE datalink;
CREATE TABLE datalink
(
datalink_id serial NOT NULL,
datalink_type character varying(50) NOT NULL DEFAULT ''::character varying,
--georss,kml,gml,geojson
datalink_type_version character varying(50) NOT NULL DEFAULT ''::character
varying, --1.0,3.x?
datalink_url text,
datalink_owner integer,
datalink_timestamp integer,
datalink_timestamp_create integer,
datalink_timestamp_last_usage integer,
datalink_abstract text,
datalink_title character varying(255) NOT NULL DEFAULT ''::character
varying,
datalink_data text, --maybe we want a data access for inspire and the data
should stand on the geoportal cause the institutions have no webserver
</pre>
</blockquote>
<br>
Usually, one wouldn't store different data formats (kml is different
from geojson etc.) in one column, but in this case it doesn't sound too
bad.<br>
<br>
<blockquote
cite="mid:201008051209.47495.armin.retterath@lvermgeo.rlp.de"
type="cite">
<pre wrap=""> datalink_network_access integer,
datalink_owsproxy character varying(50),
fees character varying(255),
accessconstraints text,
CONSTRAINT pk_datalink_id PRIMARY KEY (datalink_id),
--delete orphaned datalinks automatically
CONSTRAINT datalink_owner_fkey FOREIGN KEY (datalink_owner)
REFERENCES mb_user (mb_user_id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE
)
WITH (
OIDS=FALSE
);
ALTER TABLE datalink OWNER TO postgres;
</pre>
</blockquote>
<br>
Why do most (!) of the columns have a "datalink_"-prefix? I faintly
remember a short discussion on this list about column names, started by
Karim I guess.<br>
<br>
<blockquote
cite="mid:201008051209.47495.armin.retterath@lvermgeo.rlp.de"
type="cite">
<pre wrap="">
-- Table: datalink_keyword
-- DROP TABLE datalink_keyword;
CREATE TABLE datalink_keyword
(
fkey_datalink_id integer NOT NULL,
fkey_keyword_id integer NOT NULL,
CONSTRAINT pk_datalink_keyword PRIMARY KEY (fkey_datalink_id,
fkey_keyword_id),
CONSTRAINT fkey_keyword_id_fkey_datalink_id FOREIGN KEY (fkey_keyword_id)
REFERENCES keyword (keyword_id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT fkey_datalink_id_fkey_keyword_id FOREIGN KEY (fkey_datalink_id)
REFERENCES datalink (datalink_id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE
)
WITH (
OIDS=FALSE
);
ALTER TABLE datalink_keyword OWNER TO postgres;
-- Table: datalink_md_topic_category
-- DROP TABLE datalink_md_topic_category;
CREATE TABLE datalink_md_topic_category
(
fkey_datalink_id integer NOT NULL,
fkey_md_topic_category_id integer NOT NULL,
CONSTRAINT datalink_md_topic_category_fkey_datalink_id_fkey FOREIGN KEY
(fkey_datalink_id)
REFERENCES datalink (datalink_id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT datalink_md_topic_category_fkey_md_topic_category_id_fkey FOREIGN
KEY (fkey_md_topic_category_id)
REFERENCES md_topic_category (md_topic_category_id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE
)
WITH (
OIDS=FALSE
);
ALTER TABLE datalink_md_topic_category OWNER TO postgres;
2) another demand in our application is a solution for an automatic update
process for webservices. many wms are somewhat dynamically - layers go away
and other layers will newly be generated. in such a case it is too much work
to update the service by hand! we want ti implement a user interface where the
owners of the services can define an update interval to steer the update
process. maybe - daily, weekly or monthly. further they can define if new
layers/featuretypes should be accessible/searchable direct after the update
process - or - that the owner should manage this interactively.
</pre>
</blockquote>
<br>
Another cool idea!<br>
<br>
<blockquote
cite="mid:201008051209.47495.armin.retterath@lvermgeo.rlp.de"
type="cite">
<pre wrap="">draft for a new mapbender database table:
-- Table: auto_update
-- DROP TABLE auto_update;
CREATE TABLE auto_update
(
auto_update_id serial NOT NULL,
auto_update_type character varying(50) NOT NULL DEFAULT ''::character
varying, --wms,wfs,datalink
fkey_wms_id integer,
fkey_wfs_id integer,
fkey_datalink_id integer,
auto_update_interval character varying(50) NOT NULL DEFAULT ''::character
varying, --d,w,m
</pre>
</blockquote>
<br>
Maybe (!) a better datatype choice would be interval:<br>
<a class="moz-txt-link-freetext" href="http://www.postgresql.org/docs/8.4/interactive/datatype-datetime.html#DATATYPE-INTERVAL-INPUT">http://www.postgresql.org/docs/8.4/interactive/datatype-datetime.html#DATATYPE-INTERVAL-INPUT</a><br>
<br>
I have never really worked with it, but it might provide greater
flexibility. <br>
<br>
<blockquote
cite="mid:201008051209.47495.armin.retterath@lvermgeo.rlp.de"
type="cite">
<pre wrap=""> auto_update_mail boolean,
auto_update_access integer, --1 - activate access automatically,0 -- don't
activate access
auto_update_publish, --1 - publish resource automatically, 0 - hide resource
first - user has to publish
auto_update_timestamp integer, -- time when auto_update has been defined or
last changed
auto_update_timestamp_last_update integer,
auto_update_status integer,
auto_update_status_error_message text,
CONSTRAINT pk_auto_update_id PRIMARY KEY (auto_update_id),
CONSTRAINT auto_update_fkey_wms_id_fkey FOREIGN KEY (fkey_wms_id)
REFERENCES wms (wms_id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT auto_update_fkey_wfs_id_fkey FOREIGN KEY (fkey_wfs_id)
REFERENCES wfs (wfs_id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT auto_update_fkey_datalink_id_fkey FOREIGN KEY (fkey_datalink_id)
REFERENCES datalink (datalink_id) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE
)
WITH (
OIDS=FALSE
);
ALTER TABLE auto_update OWNER TO postgres;
please feel free to answer if you have problems or have some good ideas to
extent this functions.
regards
armin
</pre>
</blockquote>
<br>
Very interesting proposals, thanks for sharing.<br>
<br>
Best regards,<br>
Marc<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
.................................................................
Karten im (Inter|Intra)net?
OpenLayers - Webentwicklung mit dynamischen Karten und Geodaten
von M. Jansen und T. Adams, OpenSourcePress, München.
ISBN: 978-3-937514-92-5
URL: <a class="moz-txt-link-freetext" href="http://openlayers-buch.de">http://openlayers-buch.de</a>
.................................................................
Dipl.-Geogr. Marc Jansen
- Anwendungsentwickler -
terrestris GmbH & Co. KG
Irmintrudisstraße 17
53111 Bonn
Tel: ++49 (0)228 / 96 28 99 -53
Fax: ++49 (0)228 / 96 28 99 -57
Email: <a class="moz-txt-link-abbreviated" href="mailto:jansen@terrestris.de">jansen@terrestris.de</a>
Web: <a class="moz-txt-link-freetext" href="http://www.terrestris.de">http://www.terrestris.de</a>
Amtsgericht Bonn, HRA 6835
Komplementärin: terrestris Verwaltungsgesellschaft mbH
vertreten durch: Hinrich Paulsen, Till Adams
</pre>
</body>
</html>