Open cvvergara opened 7 years ago
ingore the names, the names are not yet the final names
orders_sql
id BIGINT,
demand FLOAT,
pick_x FLOAT,
pick_y FLOAT,
pick_open TIMESTAMP,
pick_close TIMESTAMP,
pick_service FLOAT,
drop_x FLOAT,
drop_y FLOAT,
drop_open TIMESTAMP,
drop_close TIMESTAMP,
drop_service FLOAT
);
I must say that service is service_time :
pick_service TIMESTAMP,
drop_service TIMESTAMP
About TIMESTAMP:
This is clear for a postgreSQL user: (which btw I am not one yet, except for testing pgRouting) https://www.postgresql.org/docs/9.1/static/datatype-datetime.html
The user can choose how to store the time:
type | size |
---|---|
timestamp [ (p) ] [ without time zone ] | 8 bytes |
timestamp [ (p) ] with time zone | 8 bytes |
date | 4 bytes |
time [ (p) ] [ without time zone ] | 8 bytes |
time [ (p) ] with time zone | 12 bytes |
interval [ fields ] [ (p) ] | 16 bits |
I can read the code and try to figure out how to interpret the structure
C++ time handling is available on C++11; On v2.0 and before, pgRouting was using C++98, now its using C++0x, not yet using C++11 So, the time handling has to be done then with postgresql time structures and functions:
pick&deliver is all times so: for example after calculating the euclidean distance and given a speed, get the time:
time = distance / speed
reals
/* keep this struct small; it gets used a lot */
210 typedef struct
211 {
212 char token[TOKMAXLEN + 1]; /* always NUL-terminated */
213 char type; /* see field type codes above */
214 int32 value; /* meaning depends on type */
215 } datetkn;
216
"meaning depends on the type" On postgreSQL what type has what meaning. or is it for the user what meaning has what type?
Postgres is all written on C, if going to use internally the TIMESTAMP code on C++, Then basically the C++ code will depend on postgres code
I already manage to only use postgres code on the C code and the C++ "driver" code that connects the C with C++ code uses only palloc & pfree (took me about 1 1/2 years to find out how to do it, before that was using malloc) (this possibility is top secret) The fact that the C++ code of pgRouting does not need the postgres code gives the opportunity to use pgRouting C++ code independently of the postgreSQL database because the heart of pgRouting is about the algorithms not about how the data is stored. the C/driver (inC++) codes are just connectors. So using the postgres C code in the C++ will have the draw back of not being able to do the top secret possibility
Difficult enough was to figure out how to use palloc and pfree on the dirvers! which by the way is the only postgres code used on the drivers.
About GEOMETRY
This is a geometry:
010200000002000000000000000000004000000000000000000000000000000040000000000000F03F
This is also a geometry:
010100000000000000000000400000000000000000
Validation is needed:
ERROR: Argument to ST_X() must be a point
This snipet shows how a pgRouting function is defined at postgres level:
CREATE OR REPLACE FUNCTION pgr_floydWarshall(edges_sql TEXT, directed BOOLEAN DEFAULT TRUE,
OUT start_vid BIGINT, OUT end_vid BIGINT, OUT agg_cost float)
RETURNS SETOF RECORD AS
'$libdir/${PGROUTING_LIBRARY_NAME}', 'floydWarshall'
LANGUAGE c IMMUTABLE STRICT;
Suppose that one of the columns in edges_sql is of type GEOMETRY https://github.com/pgRouting/pgrouting/blob/master/src/common/src/get_check_data.c#L73 it will need to check if its a geometry then a new function similar to: https://github.com/pgRouting/pgrouting/blob/master/src/common/src/get_check_data.c#L125 and similar to this snipet
PG_FUNCTION_INFO_V1(LWGEOM_length_linestring);
312 Datum LWGEOM_length_linestring(PG_FUNCTION_ARGS)
313 {
314 GSERIALIZED *geom = PG_GETARG_GSERIALIZED_P(0);
315 LWGEOM *lwgeom = lwgeom_from_gserialized(geom);
316 double dist = lwgeom_length(lwgeom);
317 lwgeom_free(lwgeom);
318 PG_FREE_IF_COPY(geom, 0);
319 PG_RETURN_FLOAT8(dist);
320 }
to get the actual value geometry value. but for doing that, postGIS source code would be needed for the includes that might be needed:
30 #include "utils/geo_decls.h"
31
32 #include "../postgis_config.h"
33 #include "liblwgeom.h"
34 #include "lwgeom_pg.h"
35
Which means adding dependencies for compiling pgRouting like liblwgeom and maybe postgis itself.
I am closing, because at the end it looks like one of my monologues
discussion about types started here:
https://github.com/pgRouting/pgrouting/issues/520