[udig-devel] clem

[Rob Atkinson]

Hi John,
(again? - I think we discussed this a while back on OpenSDI, no?)

Hi again Bryce

You guys are touching some spaces where there is some existing work, and 
ongoing work that I suspect needs your input :-)

There is detailed discussion of the state of play in terms of formal 
methods to model features in UML at

https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/WebHome

There are a number of threads where we aim to develop and promote 
improved experience and power of the tools:

Under way:
1) Support for a common, formal, mechanism to allow simplified views 
(typically GML Level 0,1 profiles) and legacy views against a shared 
conceptual model
2) Eclipse plugin for the "UGAS" (aka ShapeChange) UML -> GML schema 
automation tool (using ISO 19118 rules)
3) Modularisation of the modelling framework to allow external models 
and schemas to be effectively imported

In research and planning:
4) geoserver WCS / geotools coverage /FM branch convergence
5) Supporting the Observations and Measurements patterns with easy 
configuration capabilities

FYI I have been pouring UML models using O&M and ISO base packages into 
the Geoserver "complex-features" branch for a while, and am waiting for 
FM to come home so that I can start to exercise and debug it.


We'd be most interested to share thoughts about the relationships 
between coverages and FM, since Bryce has probably looked much deeper 
into this than anyone else.

When I say "we" - there is a group of people who include key players in 
the OGC and ISO specs world, and one sponsor of some effort in the UK 
Met Office, who faces the task of creating sensible data standards and 
appropriate tools to handle them for the meteorology domain. So, UK MO 
will be the gatekeepers for my effort in the short term, but they have 
significant internal capability and project partners with resources 
willing to look into these matters.

Specifically, we want a Geoserver capability able to support coverages 
via WFS and WCS, and also the general feature model - time-series, 
objects with multiple geometries. I'd have thought a sensible, 
comprehensive, test case would be the ability to create a function that 
intersected a locus (3D trajectory) with a 4-D coverage and created a 
profile, and was able to serve profile this as an XML encoded GML 
feature or a binary-encoded "coverage" format. This function doesnt need 
to be defined or managed at run-time - it can be plugged in as code if 
necessary, but the feature model has to allow passing the input locus as 
a feature into the function, and the serialisation of the result as GML 
or a binary object.

At the very least, we'd appreciate it if you could identify the 
functionality you are targetting, and propose some test cases that can 
be used to test whether anything we plan is going to break what you 
need, or if what you are doing is going to serve our needs in the short 
term.

PS - I also want to get my head around this to fulfil expectations of my 
role on the Geoserver Project Steering Committee :-)  Help me help you!


NB The ShapeChange tool currents reads XMI, and it would take a bit of 
effort to make it read directly from an in-memory model, and the UML 
plug-ins for Eclipse didnt look worth the effort yet. Adam Flaherty at 
the UK Met Office has looked deeper into this and may be able to provide 
more explicit insight into the issues here.

Nevertheless, this is not such an issue since:
a) any modelling tool ought to be able to serialise the model into XMI 
for management, transfer and archiving
b) GML schema is a lossy serialisation - the model will contain more 
information than can be expressed unambiguously in GML/XML  schema
c) UML -> XMI -> GML is not that onerous and could be automated within 
Eclipse I'd have thought

The big issues informing models are how to modularise them. I strongly 
suggest you look at the HollowWorld template provide at the website above.
If you dont want to buy Enterprise Architect then it should be possible 
to use ArgoUML or some other tool - and it would be a useful 
contribution to test this out.


Regards

Rob Atkinson


John Reid <sdiowl at yahoo.com.au> wrote on 07/25/2006 09:02:18 AM:


> > Guess I should start by introducing myself properly  :-)   My name's
> > John Reid.
>   

Welcome aboard!


>> > > Hmmm... a _graphical_ modeling tool, or an Ecore adapter?
>>     

> > Bryce, you nailed it.  From a quick initial read of docs I think
> > I'll need both.  My initial idea was to:
> > 1. Define a UML profile for geographic features
> > 2. Use a (possibly customized) heavy-weight UML 2.0 graphical
> > modeling tool to do the hard work.  I'm currently looking at Visual UML
> > 3. Use XMI and UML 2.0 Diagram Interchange files for native model
> > persistence and publishing
> > 4. Provide adapters to read/write ISO compliant XML schemas
>   

I'm getting lost in terminology.  This happens to me a lot.   :) 

1] My understanding is that the UML encoding of Geographic features was
handed to us from on high in 19109, Clause 8 (I think).  Are you talking
about drawing out the required UML (e.g. '107, '108, '111, '112, '115...)
in a specific UML tool?  Or are you talking about something else when you
say a "profile"?  Perhaps drawing out a particular subset of '107, etc.

2&3 ] Bravo!

4] ? Which ISO compliant XML schemas?  GML 3.2.0 / ISO 19139?

Beware of the GT/GeoAPI Feature Model.  You may get some data which is not
strictly ISO compliant (making it difficult to encode it in an ISO
compliant way.)  Jody insisted on allowing for non-OGC non-ISO features
merely because customers generate all manner of garbage XML and he's afraid
to call them wrong.   :)   Due to much whining on my part, they made
allowances for people who play by the rules, but I think this is optional.
It has been a while since I looked at the Feature Model.  I suggest you
examine it to ensure that you can extract an appropriate guarantee that
feature schema you receive will be encode-able...Pay particular attention
to duplicate feature attributes.  Jody, can you direct this fine young man
to the ISO subset of the feature model?

Also beware of GML.  Making an XML schema seems to invite people to
disregard all else.  The XML Schema for GML permits more than is allowed by
the text of the GML standard, and also more than is allowed by the data
model GML is supposed to represent.  People will argue that anything that
validates against the schema should be considered "legal" even if it
conflicts with the text of the GML standard or the model that GML encodes.
You're going to have to defend your #4 from incorrect allegations of it
being broken and resist the temptation to break your codec for everyone
just because someone has produced or needs to receive data which is broken
in a specific way.  Down that road lies madness.

Not that I have any strong feelings on the issue.  :)  Nope not me.


> > I had hoped that a direct mapping could be established between a UML
> > profile and ISO 19109, however I'm now unsure if this is possible.
> > At least not with the "natural" way to use UML profiles...  It looks
> > like an additional layer will be needed to map from the Eclipse UML2
> > model to the GeoAPI interfaces and 4) can be handled by the
> > Geotools/uDig implementation of these interfaces.
>   

Again, I'm not sure I understand the word profile in this context.

I think Eclipse UML2 would only be necessary because you want to use UML2.0
Diag. Int. Files.  Ecore is much smaller and I'm nearly certain it contains
everything required to be ISO compliant (including references, inheritance,
etc.)  Is there a converter between the two?  The only reason I mention it
is because Coverages are being built as Ecore models, which should
kickstart your profileing.

The next two paragraphs are intended to convince you that you need to
declare your scope before it explodes.  :)  Don't get discouraged!  I want to
see UML schema representations happen!!

How do you intend to handle Operations?  When a geographic feature is
specified to have some sort of behavior, how do you want to match it up
with a local version of code in the current environment?  Can't code it in
UML!

More generally, say you have a shapefile containing roads which came from
some random source.  Separately, you have an ISO compliant Roads schema
which you have been working with (maybe even coding against: routing
algorithms and whatnot.)  Can you map the feature attributes in your
shapefile to identically-defined "standard" attributes in the Roads schema,
thereby making all your hard "routing" work available to you?