[Mapbender_dev] request for comments
Marc Jansen
jansen at terrestris.de
Thu Aug 5 07:59:23 EDT 2010
Hi Armin,
find (short) comments inline.
On 05.08.2010 12:09, Armin Retterath wrote:
> 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!
>
A very(!) cool idea.
* Will there be some (syntax-)validation going on?
* Which outputformats do you have in mind?
* Will it be possible to upload geojson and publish it as GML?
* If so, will these ressources be RESTful?
e.g. GET http://example.com/mapbender/datalink/42/KML
or GET http://example.com/mapbender/datalink/42/geojson (doesn't
care in which format it was once uploaded)
> 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
>
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.
> 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;
>
>
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.
> -- 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.
>
Another cool idea!
> 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
>
Maybe (!) a better datatype choice would be interval:
http://www.postgresql.org/docs/8.4/interactive/datatype-datetime.html#DATATYPE-INTERVAL-INPUT
I have never really worked with it, but it might provide greater
flexibility.
> 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
>
>
>
Very interesting proposals, thanks for sharing.
Best regards,
Marc
--
.................................................................
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: http://openlayers-buch.de
.................................................................
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: jansen at terrestris.de
Web: http://www.terrestris.de
Amtsgericht Bonn, HRA 6835
Komplementärin: terrestris Verwaltungsgesellschaft mbH
vertreten durch: Hinrich Paulsen, Till Adams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapbender_dev/attachments/20100805/5a3cbff2/attachment.html
More information about the Mapbender_dev
mailing list