Diese Seite mit anderen teilen ...

Informationen zum Thema:
Forum:
WinDev Forum
Beiträge im Thema:
3
Erster Beitrag:
vor 5 Monaten, 2 Wochen
Letzter Beitrag:
vor 5 Monaten, 2 Wochen
Beteiligte Autoren:
DarrenF, Fabrice Harari

[WX22] A bit of Google Maps (or alternative) advice required...

Startbeitrag von DarrenF am 06.06.2017 13:18

Hi guys,

Some advice on a requirement I have from a customer would be appreciated... Has anyone used Google Maps (or similar) to implement a delivery roster system?

The basic scenario is, web site receives product orders, then the back office (admin side) of the system would interrogate the orders and:
1) At a certain time of the day (cut-off point), would allocate the web site orders into delivery zones giving each driver a sequence of delivery and directions to each delivery/drop-off.
2) Must take product size and weight into account so that items will a) fit onto the van and b) not overload the van.
3) Must take into account the driving time to each drop-off point (+ a notional "unloading" time), so as to make all the deliveries possible in a given time-frame e.g. 8am to 4pm.

There will be other areas to consider, but if I can achieve the above in v1 then that would be a great starting point!

Any general advice around your experiences and/or pointers (like websites or blogs) would be greatly appreciated...

Thanks in advance... :spos:

Antworten:

Hi Darren,

About points 1 and 3:
I worked a little bit on the delivery route problem with a customer, and I can tell you that both the google maps and the open street maps api are easy to use in windev with httprequest.

If I remember correctly, the optimized route api is limited at 10 waypoints in google (the free version) and 20 for open street map.

Also, if you are in need of a lot of calls, I think I remember that you can setup your own open street map server.

I am not talking here about the gglxxx functions readiliy available in windev, because they are only a subset of the available api and work only with the google map system.

The calculation of the driving time is a result of the google api call, so adding an unloading time x number of delivery is trivial.

as for point 2, that could prove interesting, as you have to take into account:
- the simple fact that you need to male a 3D optimized calculation, which is not trivial in itself.
- the inability of most people to set a bunch of boxes in any kind of optimized setting
- the fact that you will have to make a choice between optimizing the space occupation in the van, and optimizing the accessibility of packages in the order of delivery, thus speeding the unloading time.
- the fact that no matter what you choose above, packages will probably just end up being put in the van willy nilly, without any respect for any instruction sheet you may provide.

So, except for doing a very general/vague calculation with a WIDE margin for errors, I wouldn't bother too much about that point.

Best regards

von Fabrice Harari - am 06.06.2017 13:47
Thanks for responding Fabrice.

I'll take a look at Open Street map as well :spos: ...and the Open Street map server sounds promising.

As for point 2, I think I should be able to mitigate any issues with the fact that the majority of the packages will be "roughly" the same size (give or take a few cm's) & shape as the packages will be internal house doors with the odd small box of hinges & handles. I feel the weight limit for a van will probably be reached before physical space becomes an issue?

The process around orders that need to be taken into account per delivery route might be a manual selection process to begin with, thus avoiding some of the issues around automating the process.

von DarrenF - am 06.06.2017 15:15
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.