Warnings from parse.cc and parse_wrap.cpp files [-Wshorten-64-to-32]

kpelechrinis commented 10 years ago

Hi,

I am able to compile but I am getting warnings which I think I should not ignore. For example,

parse.cc:211:52: warning: implicit conversion loses integer precision: 'node_t' (aka 'unsigned long long') to 'int' [-Wshorten-64-to-32] ret.push_back(Edge(edges_inserted, source, id, length, car_direct, car_rev, bike_direct, bike_rev, foot, geom.str()));



I used the compiled software to obtain the network for various cities from http://metro.teczno.com but I get a number of erroneous lat/lon pairs and extremely large lengths for road segments (e.g., even one with ~ 11k miles).  I am pretty sure that this is due to the warnings raised.  I am working on trying fixing it but if you have any suggestions that would be very helpful.

Bellow are also all the warnings I am getting:

parse.cc:211:52: warning: implicit conversion loses integer precision: 'node_t' (aka 'unsigned long long') to 'int' [-Wshorten-64-to-32]
                ret.push_back(Edge(edges_inserted, source, id, length, car_direct, car_rev, bike_direct, bike_rev, foot, geom.str()));
                              ~~~~                 ^~~~~~
parse.cc:211:60: warning: implicit conversion loses integer precision: 'node_t' (aka 'unsigned long long') to 'int' [-Wshorten-64-to-32]
                ret.push_back(Edge(edges_inserted, source, id, length, car_direct, car_rev, bike_direct, bike_rev, foot, geom.str()));
                              ~~~~                         ^~
parse.cc:227:12: warning: implicit conversion loses integer precision: 'size_type' (aka 'unsigned long') to 'int' [-Wshorten-64-to-32]
    return nodes.size();
    ~~~~~~ ^~~~~~~~~~~~
parse.cc:232:12: warning: implicit conversion loses integer precision: 'const node_t' (aka 'const unsigned long long') to 'int' [-Wshorten-64-to-32]
    return ways_count;
    ~~~~~~ ^~~~~~~~~~
4 warnings generated.
parse.cc:211:52: warning: implicit conversion loses integer precision: 'node_t' (aka 'unsigned long long') to 'int' [-Wshorten-64-to-32]
                ret.push_back(Edge(edges_inserted, source, id, length, car_direct, car_rev, bike_direct, bike_rev, foot, geom.str()));
                              ~~~~                 ^~~~~~
parse.cc:211:60: warning: implicit conversion loses integer precision: 'node_t' (aka 'unsigned long long') to 'int' [-Wshorten-64-to-32]
                ret.push_back(Edge(edges_inserted, source, id, length, car_direct, car_rev, bike_direct, bike_rev, foot, geom.str()));
                              ~~~~                         ^~
parse.cc:232:12: warning: implicit conversion loses integer precision: 'const node_t' (aka 'const unsigned long long') to 'int' [-Wshorten-64-to-32]
    return ways_count;
    ~~~~~~ ^~~~~~~~~~
3 warnings generated.

parse_wrap.cpp:10182:31: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32]
  if (arg1) (arg1)->edge_id = arg2;
                            ~ ^~~~
parse_wrap.cpp:10234:30: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32]
  if (arg1) (arg1)->source = arg2;
                           ~ ^~~~
parse_wrap.cpp:10286:30: warning: implicit conversion loses integer precision: 'unsigned long' to 'int' [-Wshorten-64-to-32]
  if (arg1) (arg1)->target = arg2;
                           ~ ^~~~
3 warnings generated.

kpelechrinis commented 10 years ago

I actually did the following changes and all the warnings are gone:

At parse.h
in the definition of struct Edge I changed the types for source and target from int to unsigned long long and did the same at the line: Edge(int e, unsigned long long s, unsigned long long t, float l, char c, char cd, char b, char bd, char f, const std::string & str) :
I changed the returning type of get_osm_nodes() and get_osm_ways() from int to unsigned long and unsigned long long respectively
At parse.cc
I changed the returning type of get_osm_nodes() and get_osm_ways() to match those in parse.h
At parse.i
I changed the type of source and target in the definition of Edge struct to unsigned long long (however, even without this change it would still compile without warning).

However, despite these changes I am still getting some problematic output for some points. For example, I am getting things such as:

"node_id","longitude","latitude" 109099661,4.77735208402e-10,6.95045352799e-310 196618772,0.0,0.0

I was wondering whether anyone has faced similar problems and has figured out whether this is a problem inherent to OSM (e.g., the reports from the crowds are "erroneous") or it has to do with numerical conversions from osm4routing.

In any case these instances are not a lot (compared to the size of the network) but still it would be good to know what's going on :) Any help is appreciated!

Tristramg commented 10 years ago

Hi, thanks for this repport. First question: are you on a 32 or 64 system?

For the changes you made, please make a pull request so I can take in account your improvements.

There was a other user that also had very odd nodes as yours. I couldn’t find rapidly the reason. I’ll have to push further the investigation

kpelechrinis commented 10 years ago

Hi, I am using a 64-bit machine. Actually I think I figured out the reason for these odd nodes. The osm file includes information about nodes and ways within a bounding box. These "odd nodes" are essentially nodes whose definition (e.g., lat/lon) does not exist in the input osm extract file because they are out of the bounding box, which was used to create the osm file. However there are ways that include these ids, since these ways extend outside of the bounding box; inevitably osm4routing does not know what to do with these nodes. I actually checked the osm input file and I indeed found the odds' node IDs only as part of a "way definition" and no information about their lat/lon exists. Also I checked some of the ways that include these nodes and are indeed at the border of the bounding box. Hence, I do not think there is something here due to osm4routing. I am assuming that this might be the reason for other users too.

I will also make a pull request later for the changes I made for the warning messages, since I cannot access my code for some reason right now.

Again thanks a lot for responding that fast to my message and for the great tool you have provided here!

Tristramg commented 10 years ago

Hello,

Thanks, indeed the missing nodes seems very plausible. I had this issue with osmosis (but it includes a flag to reference all the nodes so I didn’t bother much). I will add some way to ignore such nodes, as it is difficult to ignore the metro extracts.

And thank you for being interested in this tool ;)

On 4 November 2013 03:01, kpelechrinis notifications@github.com wrote:

Hi, I am using a 64-bit machine. Actually I think I figured out the reason for these odd nodes. The osm file includes information about nodes and ways within a bounding box. These "odd nodes" are essentially nodes whose definition (e.g., lat/lon) does not exist in the input osm extract file because they are out of the bounding box, which was used to create the osm file. However there are ways that include these ids, since these ways extend outside of the bounding box; inevitably osm4routing does not know what to do with these nodes. I actually checked the osm input file and I indeed found the odds' node IDs only as part of a "way definition" and no information about their lat/lon exists. Also I checked some of the ways that include these nodes and are indeed at the border of the bounding box. Hence, I do not think there is something here due to osm4routing. I am assuming that this might be the reason for other users too.

I will also make a pull request later for the changes I made for the warning messages, since I cannot access my code for some reason right now.

Again thanks a lot for responding that fast to my message and for the great tool you have provided here!

— Reply to this email directly or view it on GitHubhttps://github.com/Tristramg/osm4routing/issues/11#issuecomment-27661060 .

Tristramg commented 10 years ago

Solved by https://github.com/Tristramg/osm4routing/pull/12

Tristramg commented 10 years ago

Hello,

I fixed (at least I hope) at last this issue.

Please tell me if it’s still bad

On 4 November 2013 03:01, kpelechrinis notifications@github.com wrote:

Hi, I am using a 64-bit machine. Actually I think I figured out the reason for these odd nodes. The osm file includes information about nodes and ways within a bounding box. These "odd nodes" are essentially nodes whose definition (e.g., lat/lon) does not exist in the input osm extract file because they are out of the bounding box, which was used to create the osm file. However there are ways that include these ids, since these ways extend outside of the bounding box; inevitably osm4routing does not know what to do with these nodes. I actually checked the osm input file and I indeed found the odds' node IDs only as part of a "way definition" and no information about their lat/lon exists. Also I checked some of the ways that include these nodes and are indeed at the border of the bounding box. Hence, I do not think there is something here due to osm4routing. I am assuming that this might be the reason for other users too.

I will also make a pull request later for the changes I made for the warning messages, since I cannot access my code for some reason right now.

Again thanks a lot for responding that fast to my message and for the great tool you have provided here!

— Reply to this email directly or view it on GitHubhttps://github.com/Tristramg/osm4routing/issues/11#issuecomment-27661060 .

kpelechrinis commented 10 years ago

Thanks for taking care of it!

Tristramg / osm4routing

Warnings from parse.cc and parse_wrap.cpp files [-Wshorten-64-to-32] #11