[fdo-internals] Standardising FDO Schema's

Wed Sep 3 10:57:19 EDT 2008

The stylization engine is not only FDO-backed. It exposes an interface which wraps an FDO FeatureReader -- or some other reader if one chooses to. The rendering code itself can also be used in immediate mode (i.e. without a feature iterator, or without MapGuide whatsoever).

Traian

> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
> Sent: Wednesday, September 03, 2008 10:28 AM
> To: 'FDO Internals Mail List'
> Subject: RE: [fdo-internals] Standardising FDO Schema's
>
> 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
>
>
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals