1

Is it possible to change the projection used in OSM2PO? I used the following command to generate a SQL file which I loaded into my database:

java -jar osm2po-core-4.2.30-signed.jar prefix=at "filename.osm.pbf.pbf"

This produce the file at_2po_4pgr.sql. I then loaded this file into my postgres database:

psql -U postgres  -d routing -a -f at_2po_4pgr.sql

As this table is based on SRID:4326, I wondered if there was any way of changing it so that I can use a different projection system. The columns in the table are as follows:

  id integer NOT NULL,
  osm_id bigint,
  osm_name character varying,
  osm_source_id bigint,
  osm_target_id bigint,
  clazz integer,
  flags integer,
  source integer,
  target integer,
  km double precision,
  kmh integer,
  cost double precision,
  reverse_cost double precision,
  x1 double precision,
  y1 double precision,
  x2 double precision,
  y2 double precision,
  geom_way geometry(LineString,4326),
  CONSTRAINT pkey_at_2po_4pgr PRIMARY KEY (id)

I know that I can use ST_Transform to convertgeom_way` into a different projection but I was unsure how to update any of the other values as I presumed some were based on the initial projection.

Improve this question

3 Answers 3

Reset to default
2

osm2po does export EPSG 4326 only.

As geom_way is a pure PosgGIS data type, you can indeed change it using ST_Transform. x1, y1, x2, y2 are hard coded values for pgRouting's aStar. I do not know what will happen if you transform them also.

Improve this answer
2
  • I don't think it's possible to transform x1, y1, x2, y2 as they are not geometric or geographic objects. However, if they are only used for aStar maybe it it does not matter too much.
    – djq
    Commented Oct 10, 2012 at 16:34
  • Yes, they are only used for aStar. Maybe Daniel is following this thread and can give you some more infos.
    – Carsten
    Commented Oct 10, 2012 at 16:59
1

How about

 ST_Transform(geom_way,<new crs>)

Then update x1,y1,x2,y2

 UPDATE table_name SET x1 = X(ST_StartPoint(geom_way))

etc.

Same for updating km and the related cost

 UPDATE table_name SET km = ST_Length(geom_way)
Improve this answer
3
  • I'll try it out. I was a bit nervous changing it in case I misunderstood how these values were being calculated but this seems like a good approach.
    – djq
    Commented Oct 10, 2012 at 18:28
  • Hmmm. The major question is, if pgRouting looks up the srs in the spatialRefSys- and geometry-colums-Table or not. If it depends on WGS84, there is nothing to change here because these values are only used for calculating heuristics.
    – Carsten
    Commented Oct 10, 2012 at 19:10
  • While I cannot be absolutely certain without looking into the sources, I certainly wouldn't expect pgRouting to be CRS dependent.
    – underdark
    Commented Oct 10, 2012 at 19:42
0

I've included how I did this using @underdark's suggestion. Perhaps of use to someone else:

CREATE TABLE osm2po_routing_prj AS
SELECT
  id,
  osm_id,
  osm_name,
  osm_source_id,
  osm_target_id,
  clazz,
  flags,
  source,
  target,
  ST_Length(ST_Transform(geom_way, 900913)) as km,
  kmh,
  cost,
  reverse_cost,
  ST_X(ST_StartPoint(ST_Transform(geom_way, 900913))) as x1,
  ST_Y(ST_StartPoint(ST_Transform(geom_way, 900913))) as y1,
  ST_X(ST_EndPoint(ST_Transform(geom_way, 900913))) as x2,
  ST_Y(ST_EndPoint(ST_Transform(geom_way, 900913))) as y2,
  ST_Transform(geom_way, 900913) as geom_way
FROM osm2po_routing;
Improve this answer
3
  • 1
    Just be aware that length measurements in 900913 can be quite wrong.
    – underdark
    Commented Oct 11, 2012 at 15:34
  • True, good point.
    – djq
    Commented Oct 11, 2012 at 15:37
  • Anyway, I think it is not necessary to reproject a length.
    – Carsten
    Commented Oct 11, 2012 at 15:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.