spatial types/queries in ofbiz

[Rajesh Mallah]

Hi ,

Many database platforms have support for geometry / geography types
that can enhance functionality of OFBiz.

Eg GeoPoint entity has longitude/latitude varchar fields which can also be
stored
in a  "geography(Point,4326)" type supported in postgres via postgis
extension.

Such types supports many spatial functions and indexes that makes many
operations
effortless.

My Question is what is the suggested way of extending OFBiz entities for
adding
columns in a way which can be maintained  across OFBiz upgrades.
At this moment i maintain a separate namespace other than ofbiz tables for
storing
such DB and application specific fields that are linked to ofbiz tables by
primary key
(generally). Is there other ways of doing this?

regds
mallah.

[Jacques Le Roux]

Le 20/10/2019 à 17:20, Rajesh Mallah a écrit :

> Hi ,
>
> Many database platforms have support for geometry / geography types
> that can enhance functionality of OFBiz.
>
> Eg GeoPoint entity has longitude/latitude varchar fields which can also be
> stored
> in a  "geography(Point,4326)" type supported in postgres via postgis
> extension.
>
> Such types supports many spatial functions and indexes that makes many
> operations
> effortless.
>
> My Question is what is the suggested way of extending OFBiz entities for
> adding
> columns in a way which can be maintained  across OFBiz upgrades.
> At this moment i maintain a separate namespace other than ofbiz tables for
> storing
> such DB and application specific fields that are linked to ofbiz tables by
> primary key
> (generally). Is there other ways of doing this?
>
> regds
> mallah.

Hi  Rajesh,

It's old, but are you aware of https://cwiki.apache.org/confluence/display/OFBIZ/Connecting+OFBiz+to+PostGIS+spatially-enabled+database ?

Not sure it's much helpful though

Jacques

[Pierre Smits-3]

Hi  Rajesh,

The entity engine is intended to make OFBiz database agnostic, but OFBiz
can be extended to be GIS (spatial) aware.

One option is to use the GeoPoint entity to capture/store/retrieve the
geometry values. In that case I suggest to define the geometry types
(point, line string, polygon, etc.) as GeoPointType values in the
Enumeration entity, and set the geometric value in the information field of
the GeoPoint record. And let/have the api/function/code work with the data
from the record.

An example of a GeoPoint record could thus be:

<GeoPoint description="example geo point" geoPointId="aa"
geoPointTypeEnumId="point" information="x,y"/>

or

<GeoPoint description="exampl geo line" geoPointId="ab"
geoPointTypeEnumId="linestring" information="0,0,0,10,0"/>



Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Sun, Oct 20, 2019 at 5:20 PM Rajesh Mallah <[hidden email]>
wrote:

> Hi ,
>
> Many database platforms have support for geometry / geography types
> that can enhance functionality of OFBiz.
>
> Eg GeoPoint entity has longitude/latitude varchar fields which can also be
> stored
> in a  "geography(Point,4326)" type supported in postgres via postgis
> extension.
>
> Such types supports many spatial functions and indexes that makes many
> operations
> effortless.
>
> My Question is what is the suggested way of extending OFBiz entities for
> adding
> columns in a way which can be maintained  across OFBiz upgrades.
> At this moment i maintain a separate namespace other than ofbiz tables for
> storing
> such DB and application specific fields that are linked to ofbiz tables by
> primary key
> (generally). Is there other ways of doing this?
>
> regds
> mallah.
>