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 <[EMAIL PROTECTED]> 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? > >
