Add geolocation on most of dolibarr objects

Dolibarr / dolibarr

Dolibarr ERP CRM is a modern software package to manage your company or foundation's activity (contacts, suppliers, invoices, orders, stocks, agenda, accounting, ...). it's an open source Web application (written in PHP) designed for businesses of any sizes, foundations and freelancers.

https://www.dolibarr.org

GNU General Public License v3.0

5.44k stars 2.79k forks source link

Add geolocation on most of dolibarr objects #26111

Open rycks opened 1 year ago

rycks commented 1 year ago

Feature Request

There is a geo URI scheme: https://en.wikipedia.org/wiki/Geo_URI_scheme since 2010 ... and i make a proposition to add geo entries in most of dolibarr objects.

For example on socpeople (delivery address), entrepot (location), fichinter(where to go) and so on. Not only "postal address" like we have for the moment.

What about the datamodel ?

MySQL/MariaDB/PostgreSQL seems to have a POINT datatype for that:

Then it seems to be the most optimal way to store that data ... what do you think about that feature request ?

Use case

Easy way to find all my customer near than a point.

More accurate data than "postal address" for parts of earth where "postal address" is a sort of graal.

Example:

<a href="geo:37.786971,-122.399677">Direct GeoLocation</a>

Suggested implementation

No response

Suggested steps

No response

JoAnMaFe commented 1 year ago

From my point of view, this is a good contribution and would significantly help the pick-up and delivery options, as well as the definition and location of customers and warehouses.

Ashley-Butcher commented 1 year ago

If this is to be implemented, then whoever implements it needs to be conscious of different spacial reference systems and choose a common system for storing points in Dolibarr. It's important because while geospacial data is commonly using WGS-84 (like Google Maps or indeed the geo URI in the feature request), sometimes databases such as post code databases use some more national-specific coordinate system and requires conversion.

Some obvious examples I've run into over the years beyond some paid national post code databases are couriers like UPS and FedEx who don't use WGS-84 for their interfaces.

It may as well be standardised as WGS-84 since it's so common, but it should be standardised for the project. Without it, it's like a date/time without a timezone.

hansemschnokeloch commented 1 year ago

We should also add altitude. This would open the way to warehouse stock management with an indication of the storage location of a product (location with level on the storage rack).

JoAnMaFe commented 1 year ago

OK.

Ashley-Butcher commented 1 year ago

@hansemschnokeloch I don't think altitude is a useful measure for determining stock location. If you want accurate stock location, you should follow the standard Warehouse -> Aisle -> Rack -> Shelf -> Bin location used standard in the WMS world. I don't see how altitude would be more useful than just knowing what shelf it's on, and specifying a shelf is much simpler to implement and manage than altitude.

After decades working with ERP and WMS systems, it seems like it would just overly complicate things IMHO, so it's logical why it's never implemented like that.