[fdo-internals] Standardising FDO Schema's

Wed Sep 3 10:28:29 EDT 2008

Hi Carsten,

Very interesting discussion indeed. However, when talking about GIS
"components" here I think people are missing the fact that MapGuide, besides
being a web server etc, is primarily FDO-backed _stylization_ engine.
Meaning - it possesses rich spatially-oriented style-based object model for
itself. Think of KML model as of another example. Any FDO application layer
will need this stylization provider embedded too, which is what Map 3D
already does. BTW I'd be very happy to see the stylization engine API
detached from overall web server functionality which I don't need for, say,
desktop application.

Regards,
Maksim Sestic

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Carsten Hess
Sent: Wednesday, September 03, 2008 15:58
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Standardising FDO Schema's

Haris,

Well I think the layer is less tightly linked to MapGuide then you might
think. If you look at AutoCAD Map, we have the same API and a lot of shared
code with MapGuide. We sometimes call it the Platform API and use it within
Autodesk to do things similarly as to what you describe. In fact I keep
encouraging people to use these platform API's more and it is what we build
our applications on. You will find the projects files to create a lean
version of the core API's to be part of the mapguide source stream.

The biggest problem I think is that we would need an open source version
that is an AutoCAD and MapGuide independent implementation of the resource
service and feature service. The other API's including coordinate system are
already pretty independent. We have not done that yet so it is not free but
it is what I would recommend to this group if we were to entertain the
creation of an "FDO application layer" ...

Cheers,
  Carsten

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Wednesday, September 03, 2008 8:28 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Standardising FDO Schema's

Carsten,
I think yes, but layer tightly coupled with Mapguide. Some of those
functionalities I see in FDO application layer.

One of things I would like to point out is that in my opinion FDO providers
need to be very light, without extra layers (being too smart, sorry don't
know how to say it in English).

For example, I am thinking to add functionality to FDO KML provider to allow
to write data from different coordinate systems. So you can write any CS
data to KML.
Most probably , right now way to do it is to take some code from MG feature
services ( I hope a lot :) ) and put it inside FDO provider.
That is no way I would like to do it , not even if it is shared library to
use. I would rather do it in "FDO application layer".

Haris

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Carsten Hess
Sent: Wednesday, September 03, 2008 1:49 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Standardising FDO Schema's

Haris,

I wonder ... do you thinkt he MG resource service and feature service are
just that, an application layer on top of FDO? At least that is how I think
of the MG service API's quite often ...

Cheers,
  Carsten
________________________________
From: fdo-internals-bounces at lists.osgeo.org
[fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
[haris at sl-king.com]
Sent: Wednesday, September 03, 2008 6:40 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Standardising FDO Schema's

Hi Orest,

I would like to add my point here. I think naming or adding db schema name
or column name to FDO class name doesn't have anything to do with FDO
capabilities, architecture, etc... Such method was choosed to get unique FDO
class name, nothing more. Name could be any kind of random generated
character string (while it is unique inside schema).
As you said FDO class supports many geometry columns as properties and has
main geometry property. As far as I can remember it doesn't work well with
client like MG. I can't remember all issue I had, I think one of them was
spatial context. To fully support "choose any geometry property" concept
then it should not be main geometry property for FDO class.

I run into this naming problems across providers while writing Fdo2Fdo as
well as providers.
For Oracle provider we have metadata table for KML it is configuration file.

My thinking was that solution would be (again) FDO application layer. In
that middle level between application and provider such name overrides would
occur.

Haris

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest Halustchak
Sent: Tuesday, September 02, 2008 10:15 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Standardising FDO Schema's

Hi,

I don't have a problem with defining some simple conventions such as a
default schema name if one isn't specified explicitly, especially if it's a
generic issue.

However, regarding the geometry property example in the discussion where
'~GeomColName' is appended to the class name, there is another approach.
FDO allows for more than one geometry property in a class. There is one that
is tagged as the main geometry, but there can be others in the class. It's
not a common case, but I have seen examples where additional geometry
properties provide additional information for label points, schematics, or
other things. So, it is valid to generate a single feature class from an
rdbms table that has more than one geometry column. Some providers have
chosen to generate separate feature classes with only one geometry property
per class. In some ways, that is easier for a client application to deal
with, but is not an FDO restriction.
MapGuide Studio, for instance, allows you to choose which geometry property
to use when creating a layer from a feature class definition.

FDO has a component for physical schema overrides that was meant to help the
user with mapping the fdo logical elements with a data stores physical
elements. I suspect that fdo users and developers may not be finding this
that helpful as currently specified. Maybe we need to look at this in
conjunction with the other schema mapping discussions to see if improving
this may help the current issues. The theory was that it would provide users
with a way to add explicit mapping from classes and properties to physical
elements such as tables and columns for rdbms'
and also to be able to identify physical elements from the logical elements
when accessing existing schema. However, because the physical aspects of
data stores are specific to the particular formats, these overrides were
provider-dependent, with provider-dependent api, hence not easy to use with
a general client application. Providers that supported this override saved
the override mapping information in metadata tables or a configuration file.
Finding a more general way to do this by not using provider specific api's
might make this much more usable. I wonder if anyone has thoughts on this.

Thanks,
Orest.

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Friday, August 29, 2008 11:10 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Standardising FDO Schema's

I agree with Robert on this one. There's a schema (or schemas). It has a
name. It has classes. The classes have names. From the point of view of the
FDO client app, those remain consistent within the boundary of the FDO
connection.

If the provider is doing some monkeying around with class names that come
from the source database, it's the provider's job to be consistent about
handling such mangled names. How the provider does that? Who cares, as long
as it does?

Traian

From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer
Sent: Friday, August 29, 2008 10:54 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Standardising FDO Schema's

On Sat, Aug 30, 2008 at 5:08 AM, Robert Fortin
<robert.fortin at autodesk.com<mailto:robert.fortin at autodesk.com>> wrote:
As Orest said, FDO represents the data in different layer Datastore, Schema
and Class. That's the rule.  That's the standard.
The fact that some provider doesn't have/require schema doesn't mean we
don't need a generic schema representation in FDO.  It's up to the provider
to say what this schema is named and what it maps to (e.g.
default or something else). FDO doesn't impose rules around the name of the
schema.

but currently there is no standard implementation pattern! that's the
problem!
which means every implementation can be different!

should a fdo client really care about which provider and data source is
being used?

Isn't FDO meant to flatten out all these differences...

In Orest's example with the oracle database, the database already exists,
with a well known and understood access pattern right.  the database
supports the use of grants, synonyms, roles etc. there is an existing
structure in place.

create user denver identified by datamonkey grant select on parcels.denver
to denver.parcels and so on

Isn't that a much easier and better place to be managing this kind of thing?
For example, removing the schema from SHP would result that you could have 2
flavors of shp depending on the connection.  Connect to a single file and
you get no schema.  Connect to a directory and you get a schema name
"default".  SHP provider standardize to using "default" every time.
Also applications relies on that standard: there will be a schema and it
will have a name.  This result in consistant representation of the schemas
and classes in a tree view for example. Changing this behavior has impacts
on applications relying on that standard.

I agree the my suggestion of an empty schema would cause headaches, does FDO
have the concept of a default schema? Ie GetDefaultSchema()? I just know fdo
mostly from the mapguide api side of things

standardising along these lines, primarily for databases providers, means
that any updating to support this model would mostly involve removing custom
provider specific workarounds....

A lot of applications wouldn't be affected at all, they just pull whatever
structure the provider represents.

Those which do, probably have a lot of case statements to handle each
different provider's quirks, which could potentially be deleted.

z

Robert

-----Original Message-----
From:
fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounces at lists
.osgeo.org>
[mailto:fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounc
es at lists.osgeo.org>] On Behalf Of Mateusz Loskot
Sent: Friday, August 29, 2008 11:05 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Standardising FDO Schema's

Orest Halustchak wrote:
> [...]
> The above is a logical schema. How could that be mapped to physical 
> schema? The discussion started with Oracle. Let's say I have an Oracle 
> instance called ORCL. The main physical grouping mechanism that Oracle 
> has is an Oracle Owner. So, one mapping is that the FDO Data Store 
> maps to Oracle Owner, then FDO Schema.Class maps to table.
> That keeps the integrated set of data within a single Oracle owner.
> Another mapping is to map FDO schema to Oracle Owner, i.e. define 
> Oracle owners LANDUSE, TRANSPORTATION, etc. But, then how do we 
> separate CityOfDenver parcels from CityOfBoulder parcels? I could have 
> DENVER_LANDUSE, BOULDER_LANDUSE, etc. There is a third mapping 
> possible, and that's to use a separate Oracle instance for each data 
> store, but users may not want to set up separate physical instances 
> for this purpose, especially if they have a large number of data 
> stores.

Orest,

Thanks for the very in-depth explanation of schema naming issues.

But we still need a consistent way to define and describe all possibilities
of mapping and naming paths in text.
As Zac proves, using only separators (like ::, ~, etc.) is insufficient.

I think more self-describing approach is needed, perhaps we would use XML or
JSON for naming schemas?

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo,
http://osgeo.org _______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org<mailto:fdo-internals at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org<mailto:fdo-internals at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/fdo-internals

--
Zac Spitzer -
http://zacster.blogspot.com (My Blog)
+61 405 847 168
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3409 (20080902) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com