Re: GIS Tools/modeling

[cjhowe]

I've dug a bit deeper into this (slowly but surely) and have a few more questions.
1) Is there any interest in having the entity engine handle database specific objects?
2) Is there any benefit in having the entity engine handle database specific objects?

I'm seeing the easiest way to handle GIS in the same manner that Al Byers did.  That is, have ofbiz load MapServer as a webapp and let that be the only communication with the geo-spatial database.  Any thoughts?

[byersa]

Chris,

I did as you said - except I loaded GeoServer, not MapServer, as a webapp -
GeoServer is Java-based and more "modern". But did you see that I also
created the WfsEventHandler and WfsViewHandler? I think that GeoServer
should be used to paint backgrounds - streets, terrain, etc. and have OFBiz
handle the points of interest thru the WftEvent/ViewHandler. I think this
will be the case with most OFBiz apps - there will be entities that have
physical locations and most of what you will want to do is plot them over
the GeoServer base layers. This is consistent with how GIS is done these
days - mashups in which data is drawn from multiple servers.

Sometimes I could imagine that the queries that you want to do on the
ofbiz-managed points of interest could get more involved than the typical
boundary rectangle search and that would be the place that the database
specific objects could come in handy. Actually that may be mostly related to
completing the WFS query operations. Right now, it only does a simple
property query - it does not even find the points within a boundary
rectangle - that would be the next task to complete.

The main place in which database specific object routines would be handy
would be when you want to store something more than simple point locations -
perhaps paths to get from one place to another, or property boundaries. You
may want to get all properties that impinge on an area.

Everything could be done via the WFS queries on the GeoServer server, but I
think things could be much difficult in some instances. There may be
occasion when you want to display points of interest that are very much
dependent on ofbiz entities - perhaps many more than you want GeoServer to
have to know about. in those cases it would be much simpler to not require
that a developer know much about Geoserver and query languages like wfs and
ofc. In fact, it would not be necessary to use the WfsEventHandler to find
points of interest; one could just do an OFBiz native search and return the
points thru the WfsViewHandler so that they could be plotted via a client
tool like Community MapBuilder.

Don't forget the availability of GeoRSS for making OFBiz entities available
to utilities like Google Maps. That is another area in which it would be
important for OFBiz to be able to handle spatial queries.

So I think the bottom line is that it will be very beneficial for OFBiz to
do some, but not the full range of GIS functions - with those functions
being specifed by WFS and GeoRSS.

I think the answer to the two questions below is that if it were simply
single points, then there would be no need to build out the entity engine
database specific objects, but if there is ever a need for polyline objects,
such as property borders, then those objects would be required. Once that is
done, you could look into tying in the GeoTools toolkit - using GeoServer as
a model. But that would probably be going to far - no need for another GIS
server. I think the dividing line is the handling of simple polyline
objects.

-Al

On 12/23/07, Chris Howe <[hidden email]> wrote:

>
> I've dug a bit deeper into this (slowly but surely) and have a few more
> questions.
> 1) Is there any interest in having the entity engine handle database
> specific objects?
> 2) Is there any benefit in having the entity engine handle database
> specific objects?
>
> I'm seeing the easiest way to handle GIS in the same manner that Al Byers
> did.  That is, have ofbiz load MapServer as a webapp and let that be the
> only communication with the geo-spatial database.  Any thoughts?
>
>

[cjhowe]

Thanks Al,
I had skipped over three important pieces of information for my current project.
1) Google Maps can handle KML and GML directly
2) Postgis has a function St_AsKML and ST_AsGml
3) The SQLProcessor in OFbiz lets me pass queries that use functions (like ST_AsKML) through it

Mixed with the widgets, I think this may end up being sufficient for my current needs.  And I don't have to worry about manipulating a GPL'd project :-)

On a side note,
If I could get the view-entity to handled the complex-alias function of ST_AsKML(the_geom), I would be completely satisfied.  But it wants to evaluate the_geom as an unsupported type first...

----- Original Message ----
From: Al Byers <[hidden email]>
To: [hidden email]
Sent: Monday, December 24, 2007 9:48:50 AM
Subject: Re: GIS Tools/modeling


Chris,

I did as you said - except I loaded GeoServer, not MapServer, as a
 webapp -
GeoServer is Java-based and more "modern". But did you see that I also
created the WfsEventHandler and WfsViewHandler? I think that GeoServer
should be used to paint backgrounds - streets, terrain, etc. and have
 OFBiz
handle the points of interest thru the WftEvent/ViewHandler. I think
 this
will be the case with most OFBiz apps - there will be entities that
 have
physical locations and most of what you will want to do is plot them
 over
the GeoServer base layers. This is consistent with how GIS is done
 these
days - mashups in which data is drawn from multiple servers.

Sometimes I could imagine that the queries that you want to do on the
ofbiz-managed points of interest could get more involved than the
 typical
boundary rectangle search and that would be the place that the database
specific objects could come in handy. Actually that may be mostly
 related to
completing the WFS query operations. Right now, it only does a simple
property query - it does not even find the points within a boundary
rectangle - that would be the next task to complete.

The main place in which database specific object routines would be
 handy
would be when you want to store something more than simple point
 locations -
perhaps paths to get from one place to another, or property boundaries.
 You
may want to get all properties that impinge on an area.

Everything could be done via the WFS queries on the GeoServer server,
 but I
think things could be much difficult in some instances. There may be
occasion when you want to display points of interest that are very much
dependent on ofbiz entities - perhaps many more than you want GeoServer
 to
have to know about. in those cases it would be much simpler to not
 require
that a developer know much about Geoserver and query languages like wfs
 and
ofc. In fact, it would not be necessary to use the WfsEventHandler to
 find
points of interest; one could just do an OFBiz native search and return
 the
points thru the WfsViewHandler so that they could be plotted via a
 client
tool like Community MapBuilder.

Don't forget the availability of GeoRSS for making OFBiz entities
 available
to utilities like Google Maps. That is another area in which it would
 be
important for OFBiz to be able to handle spatial queries.

So I think the bottom line is that it will be very beneficial for OFBiz
 to
do some, but not the full range of GIS functions - with those functions
being specifed by WFS and GeoRSS.

I think the answer to the two questions below is that if it were simply
single points, then there would be no need to build out the entity
 engine
database specific objects, but if there is ever a need for polyline
 objects,
such as property borders, then those objects would be required. Once
 that is
done, you could look into tying in the GeoTools toolkit - using
 GeoServer as
a model. But that would probably be going to far - no need for another
 GIS
server. I think the dividing line is the handling of simple polyline
objects.

-Al

On 12/23/07, Chris Howe <[hidden email]> wrote:
>
> I've dug a bit deeper into this (slowly but surely) and have a few
 more
> questions.
> 1) Is there any interest in having the entity engine handle database
> specific objects?
> 2) Is there any benefit in having the entity engine handle database
> specific objects?
>
> I'm seeing the easiest way to handle GIS in the same manner that Al
 Byers
> did.  That is, have ofbiz load MapServer as a webapp and let that be
 the
> only communication with the geo-spatial database.  Any thoughts?
>
>