Standardising FDO Schema's
|
|
| 1 2 |
zspitzer
|
Hey everyone,
I have written up some ideas on FDO schema's as they stand and making them provider agnostic and predictable across all FDO providers. http://zacster.blogspot.com/2008/08/some-ponderings-on-fdo-schemas.html Mateusz Loskot suggested I post this here to get some feedback and then maybe write it up into a RFC. z -- Zac Spitzer - http://zacster.blogspot.com (My Blog) +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
Orest Halustchak
|
Some javascript/style in this post has been disabled (why?)
Hi, This is a very interesting discussion. Let’s look at this from another angle. The FDO schema itself is a logical schema. The provider is
responsible for mapping the logical schema to physical implementations.
Different physical formats have different concepts and constraints. Even
between RDBMS products, there are differences. From the FDO perspective, we have the following layers. Data
store: This is actually the container or repository of an integrated set of objects.
Within a data store, objects are modeled by classes within one or more schemas. Schema:
This is a logical grouping of classes. There is no specific constraint as to
how to group classes, but the grouping is usually based on the close
relationships between classes, e.g. a LandUse schema, a Transportation schema,
a WaterUtility schema, etc. Classes:
Describes the type of a real world object. Etc. Consider this example. LandUse
Schema: Classes:
Parcel, Park, Lake, Agricultural, Industrial, … Transportation
Schema: Classes:
Interstate, Highway, Road, Railway, BikePath, … WaterUtility
Schema: Classes:
WaterPipe, WasteWaterPipe, Valve, … GasUtility
Schema: Classes:
Pipe, Valve, … Now, I may have a number of data stores that use the above:
CityOfDenver, CityOfBoulder, CityOfColoradoSprings, … 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. Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Zac Spitzer Hey everyone, _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Mateusz Loskot
|
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 [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Robert Fortin
|
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. 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. Robert -----Original Message----- From: [hidden email] [mailto:[hidden email]] 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Mateusz Loskot
|
Robert Fortin wrote:
> As Orest said, FDO represents the data in different layer Datastore, > Schema and Class. That's the rule. That's the standard. > [...] Robert, Yes, it's clear to me. But still the question is if a name should reflect that layering or not. Users may be confused trying to rely on schema names in more detailed way than just uniquely identifying a feature schema in connected datastore. Anyway, IMO the discussion in this thread is useful :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Haris Kurtagic
|
I fully agree with Orest and Robert.
I also understand that ~ signs in class names are not pretty. Also, even bigger problem is that is some cases after class is created with ApplySchema schema in next DescribeSchema call it will not return exact same Schema.Class name. Class name or schema name or both can be different. I have decided for KML provider to have configuration XML file in which user can set which Schema.Class name which will be returned for particullar file or url. Suggestions ideas ? Haris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Mateusz Loskot Sent: Friday, August 29, 2008 9:47 PM To: FDO Internals Mail List Subject: Re: [fdo-internals] Standardising FDO Schema's Robert Fortin wrote: > As Orest said, FDO represents the data in different layer Datastore, > Schema and Class. That's the rule. That's the standard. > [...] Robert, Yes, it's clear to me. But still the question is if a name should reflect that layering or not. Users may be confused trying to rely on schema names in more detailed way than just uniquely identifying a feature schema in connected datastore. Anyway, IMO the discussion in this thread is useful :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
zspitzer
|
In reply to this post
by Robert Fortin
On Sat, Aug 30, 2008 at 5:08 AM, Robert Fortin <[hidden email]> wrote:
As Orest said, FDO represents the data in different layer Datastore, Schema and Class. That's the rule. That's the standard. but currently there is no standard implementation pattern! that's the problem! 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. which means every implementation can be different! just focussing on the DB side for a moment, should an app really care or need to know about which fdo provider and which database i am using? Isn't FDO meant to flatten out all these differences? I am just advocating adopting a standard pattern which seeks to resolve the current inconsistencies between some fdo database provider implementations. FDO should suggest a standard model, providers can still choose to implement them or not.... In Orest's example with the oracle database, the database structure already exists, shouldn't we just try to represent that? the database supports the use of grants, synonyms, roles etc. there is an existing structure in place .. for example create user denver identified by tiger grant select on parcels.bolder create synonym parcel on parcels.bolder Isn't that a much better place to be managing this kind of thing? That way non FDO applications can also use the model. 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()? It's quite common to have qualified and unqualified naming for objects. Connect to oracle and I have access to both zac.region and region. So if FDO standardised along these lines, primarily for databases providers, updating an application to support this would mostly involve removing custom provider specific logic.... A lot of applications wouldn't be affected at all, they just pull whatever structure the provider represents. Those which do, probably have a some custom case statements to handle each different provider's quirks. Updating such applications would basically involve stripping out such custom provider specific logic, which really doesn't sound to bad to me.... Z
-- Zac Spitzer - http://zacster.blogspot.com (My Blog) +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
zspitzer
|
Sticking with your oracle example, what can be achieved in terms with
custom mappings in terms of "naming" which can't be achieved within the database, transparently to fdo? the main one which comes to mind is for making the same data in which now resides in a postgis database appear to be the same data, but named, as it used to be, when it was served thru the oracle provider? z On Sat, Aug 30, 2008 at 11:37 AM, Zac Spitzer <[hidden email]> wrote:
-- Zac Spitzer - http://zacster.blogspot.com (My Blog) +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
zspitzer
|
In reply to this post
by Robert Fortin
On Sat, Aug 30, 2008 at 5:08 AM, Robert Fortin <[hidden email]> 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
-- Zac Spitzer - http://zacster.blogspot.com (My Blog) +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Traian Stanev
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email] [mailto:[hidden email]]
On Behalf Of Zac Spitzer On Sat, Aug 30, 2008 at 5:08 AM, Robert Fortin <[hidden email]>
wrote:
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Orest Halustchak
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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:
[hidden email] [mailto:[hidden email]]
On Behalf Of Zac Spitzer On Sat, Aug 30, 2008 at 5:08 AM, Robert Fortin <[hidden email]>
wrote:
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Haris Kurtagic
|
Some javascript/style in this post has been disabled (why?)
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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Traian
Stanev 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:
[hidden email]
[mailto:[hidden email]] On Behalf Of Zac Spitzer On Sat, Aug 30, 2008 at 5:08 AM, Robert Fortin <[hidden email]>
wrote:
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Carsten Hess
|
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: [hidden email] [[hidden email]] On Behalf Of Haris Kurtagic [[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]<mailto:[hidden email]>> 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: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]<mailto:[hidden email]>] 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 [hidden email]<mailto:[hidden email]> http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email]<mailto:[hidden email]> http://lists.osgeo.org/mailman/listinfo/fdo-internals -- Zac Spitzer - http://zacster.blogspot.com (My Blog) +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Haris Kurtagic
|
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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [[hidden email]] On Behalf Of Haris Kurtagic [[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]<mailto:[hidden email]>> 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: [hidden email]<mailto:fdo-internals-bounces@lists .osgeo.org> [mailto:[hidden email]<mailto:fdo-internals-bounc [hidden email]>] 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 [hidden email]<mailto:[hidden email]> http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email]<mailto:[hidden email]> http://lists.osgeo.org/mailman/listinfo/fdo-internals -- Zac Spitzer - http://zacster.blogspot.com (My Blog) +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Carsten Hess
|
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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [[hidden email]] On Behalf Of Haris Kurtagic [[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]<mailto:[hidden email]>> 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: [hidden email]<mailto:fdo-internals-bounces@lists .osgeo.org> [mailto:[hidden email]<mailto:fdo-internals-bounc [hidden email]>] 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 [hidden email]<mailto:[hidden email]> http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email]<mailto:[hidden email]> http://lists.osgeo.org/mailman/listinfo/fdo-internals -- Zac Spitzer - http://zacster.blogspot.com (My Blog) +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Maksim Sestic
|
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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [[hidden email]] On Behalf Of Haris Kurtagic [[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]<mailto:[hidden email]>> 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: [hidden email]<mailto:fdo-internals-bounces@lists .osgeo.org> [mailto:[hidden email]<mailto:fdo-internals-bounc [hidden email]>] 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 [hidden email]<mailto:[hidden email]> http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email]<mailto:[hidden email]> http://lists.osgeo.org/mailman/listinfo/fdo-internals -- Zac Spitzer - http://zacster.blogspot.com (My Blog) +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] 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 [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Haris Kurtagic
|
In reply to this post
by Carsten Hess
Carsten,
I agree, I believe you are right. I am not familiar that well but I believe there is lot of libraries and code which can be shared. When I think of "FDO application layer" I don't mean as group of APIs, libraries shared between FDO providers or applications. I think it as one entry point to connect to FDO. There is many things to discuss but application layer is one who divide application from database drivers, divides FDO based application from FDO provider. Application connect to FDO application layer and then many things imply from that point further on. Haris -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Carsten Hess Sent: Wednesday, September 03, 2008 3:58 PM 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [[hidden email]] On Behalf Of Haris Kurtagic [[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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 <[hidden email]<mailto:[hidden email]>> 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: [hidden email]<mailto:fdo-internals-bounces@lists .osgeo.org> [mailto:[hidden email]<mailto:fdo-internals-bounc [hidden email]>] 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 [hidden email]<mailto:[hidden email]> http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email]<mailto:[hidden email]> http://lists.osgeo.org/mailman/listinfo/fdo-internals -- Zac Spitzer - http://zacster.blogspot.com (My Blog) +61 405 847 168 _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Traian Stanev
|
In reply to this post
by Maksim Sestic
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: [hidden email] [mailto:fdo-internals- > [hidden email]] 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: [hidden email] > [mailto:[hidden email]] 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: [hidden email] > [mailto:[hidden email]] 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: [hidden email] > [mailto:[hidden email]] 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: [hidden email] > [[hidden email]] On Behalf Of Haris Kurtagic > [[hidden email]] > 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: [hidden email] > [mailto:[hidden email]] 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: [hidden email] > [mailto:[hidden email]] 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: [hidden email] > [mailto:[hidden email]] 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 > <[hidden email]<mailto:[hidden email]>> 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: > [hidden email]<mailto:fdo-internals- > bounces@lists > .osgeo.org> > [mailto:[hidden email]<mailto:fdo-internals- > bounc > [hidden email]>] 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 > [hidden email]<mailto:[hidden email]> > http://lists.osgeo.org/mailman/listinfo/fdo-internals > > _______________________________________________ > fdo-internals mailing list > [hidden email]<mailto:[hidden email]> > http://lists.osgeo.org/mailman/listinfo/fdo-internals > > > > -- > Zac Spitzer - > http://zacster.blogspot.com (My Blog) > +61 405 847 168 > _______________________________________________ > fdo-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/fdo-internals > _______________________________________________ > fdo-internals mailing list > [hidden email] > http://lists.osgeo.org/mailman/listinfo/fdo-internals > _______________________________________________ > fdo-internals mailing list > [hidden email] > 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 > [hidden email] > http://lists.osgeo.org/mailman/listinfo/fdo-internals fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
Jason Birch
|
In reply to this post
by Carsten Hess
Hmm. This discussion seems like it should include the MapGuide folks :)
I would be hesitant to support the packaging of a platform service that had a dependence on DBXML. This adds a large barrier for application developers wanting to use it in proprietary or dual license models. Personally, I would much rather see strong adoption than restriction on use beyond what LGPL provides. Jason -----Original Message----- From: Carsten Hess 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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 ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
|
Jason Birch
|
Haris,
Apart from CRS handling, how do you see this application layer working? Would all applications connect to this middle tier that then manages access to the individual providers? If so, I could see this being a good place for "levelling" functionality, or a base functionality. I believe that MapGuide is doing this already for things like statistical interval calculations for theming, etc. If some effort was put into this layer, it could provide a default implementation of things like expressions, sorting, results paging, and other basic functionality that could then be overridden by individual providers when it makes sense to do so. This would ensure that all providers had basic functionality even if it was not performant, reducing the amount of capabilities checking that application developers have to do, and avoiding the LCD effect (only implementing common functionality) in independent applications. Jason -----Original Message----- From: Jason Birch Subject: [fdo-internals] Feature Service application layer (was:Standardising FDO Schema's) Hmm. This discussion seems like it should include the MapGuide folks :) I would be hesitant to support the packaging of a platform service that had a dependence on DBXML. This adds a large barrier for application developers wanting to use it in proprietary or dual license models. Personally, I would much rather see strong adoption than restriction on use beyond what LGPL provides. Jason -----Original Message----- From: Carsten Hess 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: [hidden email] [mailto:[hidden email]] 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: [hidden email] [mailto:[hidden email]] 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 ... _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals _______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
