[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