pymag-devel Mailing List for Magellan map interface for python (Page 2)
Status: Alpha
Brought to you by:
lhj
Menu
▾
▴
pymag-devel — pymagellan development
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(11) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(6) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Josh <jo...@fe...> - 2009-06-02 02:22:33
|
Quoting henrik johansson <hen...@gm...>: > Hi, > > I have now added bounding box support for the database reader. > > Think it's high time to make another release. It would be nice if you > could test the latest trunk to see if it still works for you. > > /Henrik Hi Henrik, I've done a few tests with the current svn version today, and it looks good. I haven't tried the maps on a GPSr yet but at least they don't crash mapsend ;) Most polygons are rendering now. I haven't tested the bounding box or pgsql yet. On another note, I've been getting an error for a while on one particular map I've been building: magellan/DBUtil.py:190: DeprecationWarning: 'H' format requires 0 <= number <= 65535 return apply(struct.pack, (structendian+types,) + data) magellan/Layer.py:646: DeprecationWarning: 'H' format requires 0 <= number <= 65535 return struct.pack(prefix+types, *data) I *think* this is because there are more than 64k residential/unclassified roads in the osm extract going in to a single layer. Is this a limitation of the magellan map format, or in pymag? In an attempt to overcome this in the past I've split the roads into multiple layers, and that builds successfuly. The map can be opened in Mapsend and Vantagepoint, but locks up GPSRs (tested on half a dozen explorists) as soon as you select the detail map. I don't know if this is related or a different problem. Any hints on diagnosing the problem other than trial-and-error exclusion of objects? Cheers, Josh |
|
From: henrik j. <hen...@gm...> - 2009-05-30 07:24:14
|
Hi, I have now added bounding box support for the database reader. Think it's high time to make another release. It would be nice if you could test the latest trunk to see if it still works for you. /Henrik |
|
From: henrik j. <hen...@gm...> - 2009-05-29 14:26:01
|
Hi all, I have now added PostgreSQL support in the SVN trunk. This will allow larger datasets to be processed. There is still no support for bounding box queries and the full rule set is not yet implemented. It's quite messy to import OSM data into a PostgreSQL table but there are some shell-scripts now to help a little. /Henrik |
|
From: henrik j. <hen...@gm...> - 2009-05-20 07:46:31
|
I found the problem. If the first vertex of the polygon is the same as the lower right corner of the bounding box it's of type 3. In the Bremen data set there was one polygon of type 3 which crashed MapsendLite. I have now disabled generation of type 3 polygons (they will still be generated but of another type) so it should work now. But I still don't know why type 3 makes it crash. /Henrik On 19/05/2009, henrik johansson <hen...@gm...> wrote: > Actually they are discarded, they thing is that those warnings are not > from those that make Mapsend crash. I still haven't been able to find > out those that cause the problem. In Ingo's example from Bremen I know > that there are only polygons from parks that cause problems. Far from > all parks though because I can see most of them and they look correct. > > Maybe the easiest way is to make a osm file with only those parks and > then try to find the bad ones. > > /Henrik > > On 19/05/2009, Josh <jo...@fe...> wrote: >> Oops, I had another think about that, and realised a 3 pointed closed >> polygon is actually more like a straight line ;) >> >> Is it possible to just discard bad polygons, seeing as they don't >> render anyway, and just break the map? >> >> Josh >> >> >> >> Quoting jo...@fe...: >> >>> I've just tried the latest code from svn, with mixed results. Some of >>> my maps have polygons rendering again, but others that warn about >>> Improper polygons now crash Mapsend/Vantagepoint. >>> >>> Some of the warnings I can understand - polygons with only 2 points, >>> or polygons that are 'open', but one example I saw has me confused... >>> >>> I got this warning one one tonight - >>> WARNING Improper polygon found: [(144.844255, -38.373168800000002), >>> (144.8432851, -38.373168800000002), (144.844255, -38.373168800000002)] >>> That shows a polygon with 3 points, and two of them have the same >>> coordinates? That should be a valid polygon unless I'm missing >>> something. >>> >>> The nodes/way relating to that error are: >>> >>> <node id="172752298" timestamp="2009-02-25T17:02:53Z" >>> lat="-38.3731688" lon="144.844255"/> >>> <node id="172751478" timestamp="2009-02-25T17:02:53Z" >>> lat="-38.3731688" lon="144.8432851"/> >>> >>> <way id="16711763" timestamp="2009-02-25T17:02:53Z"> >>> <nd ref="172752298"/> >>> <nd ref="172751478"/> >>> <nd ref="172752298"/> >>> <tag k="created_by" v="Potlatch 0.5d"/> >>> <tag k="leisure" v="park"/> >>> </way> >>> >>> >>> Regards, >>> Josh >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Crystal Reports - New Free Runtime and 30 Day Trial >>> Check out the new simplified licensing option that enables >>> unlimited royalty-free distribution of the report engine >>> for externally facing server and web deployment. >>> http://p.sf.net/sfu/businessobjects >>> _______________________________________________ >>> Pymag-devel mailing list >>> Pym...@li... >>> https://lists.sourceforge.net/lists/listinfo/pymag-devel >>> >> >> >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Pymag-devel mailing list >> Pym...@li... >> https://lists.sourceforge.net/lists/listinfo/pymag-devel >> > |
|
From: <jo...@fe...> - 2009-05-20 04:04:13
|
Thanks Henrik, I just saw your changes are in svn already. Looking forward to getting polygons working again! Regards, Josh Quoting henrik johansson <hen...@gm...>: > Hi Ingo, > > I tried the files and I have the same problem and I have found the bug > in CellElement.py when a polygon is created and it checks if it's a > closed polygon or not. > > Sadly, Mapsend Lite crashes when I zoom around when I have the Parks > rule active. With parks commented out in the rule file it works fine > though. I haven't yet been able to track down the offending park. > > Regards, > > Henrik > > On 13/05/2009, Ingo Hornberger <lab...@go...> wrote: >> Hi Henrik, >> >> I tried it again with the current trunk and assured that I had no >> locally changed files. But sadly with the same result. >> >> For a test I tried to render bremen.osm, because it is the smallest of >> our states in germany ;) >> >> I attached you both files. I created it with the following command: >> >> ./osmmag.py -v -n "bremen" -r data/osmmagrules.xml -o bremen.imi bremen.osm >> >> And just to make it clear: I "sourced" the "setup.sh" into my >> environment before: >> . setup.sh >> >> Best regards, >> Ingo >> >> 2009/5/11 henrik johansson <hen...@gm...>: >>> Hi Ingo, >>> >>> Strange problem. There are plenty of polygon rules in the default rule >>> file like parks and buildings. And they work fine on my explorist. >>> >>> Do you get any polygons with the default rule file? >>> >>> If you like you can send the osm-file and rule file that doesn't work >>> for you and I'll have a look. >>> >>> Best regards, >>> >>> Henrik >>> >>> 2009/5/6 Ingo Hornberger <in...@ni...>: >>>> Hi! >>>> >>>> It's me again... And again with some problems :) >>>> >>>> At the moment I am trying to generate a more complete osmmagrules.xml >>>> which should render nice maps for my eXplorist 500. The problem is >>>> that I get only roads and tracks, but I'm unable to render polygons. >>>> So I get no nice landscape ;) >>>> >>>> Is there a problem with that? If not I would be very pleased if >>>> someone can give me an example: >>>> A small osm extract with an XML file and probably also the result >>>> *.imi would do it. >>>> >>>> Probably it's only a lack of documentation ;) >>>> >>>> Thanks and best regards, >>>> Ingo >>>> >>>> ------------------------------------------------------------------------------ >>>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your >>>> production scanning environment may not be a perfect world - but thanks >>>> to >>>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK >>>> i700 >>>> Series Scanner you'll get full speed at 300 dpi even with all image >>>> processing features enabled. http://p.sf.net/sfu/kodak-com >>>> _______________________________________________ >>>> Pymag-devel mailing list >>>> Pym...@li... >>>> https://lists.sourceforge.net/lists/listinfo/pymag-devel >>>> >>> >> > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Pymag-devel mailing list > Pym...@li... > https://lists.sourceforge.net/lists/listinfo/pymag-devel > |
|
From: henrik j. <hen...@gm...> - 2009-05-19 12:44:46
|
Actually they are discarded, they thing is that those warnings are not from those that make Mapsend crash. I still haven't been able to find out those that cause the problem. In Ingo's example from Bremen I know that there are only polygons from parks that cause problems. Far from all parks though because I can see most of them and they look correct. Maybe the easiest way is to make a osm file with only those parks and then try to find the bad ones. /Henrik On 19/05/2009, Josh <jo...@fe...> wrote: > Oops, I had another think about that, and realised a 3 pointed closed > polygon is actually more like a straight line ;) > > Is it possible to just discard bad polygons, seeing as they don't > render anyway, and just break the map? > > Josh > > > > Quoting jo...@fe...: > >> I've just tried the latest code from svn, with mixed results. Some of >> my maps have polygons rendering again, but others that warn about >> Improper polygons now crash Mapsend/Vantagepoint. >> >> Some of the warnings I can understand - polygons with only 2 points, >> or polygons that are 'open', but one example I saw has me confused... >> >> I got this warning one one tonight - >> WARNING Improper polygon found: [(144.844255, -38.373168800000002), >> (144.8432851, -38.373168800000002), (144.844255, -38.373168800000002)] >> That shows a polygon with 3 points, and two of them have the same >> coordinates? That should be a valid polygon unless I'm missing >> something. >> >> The nodes/way relating to that error are: >> >> <node id="172752298" timestamp="2009-02-25T17:02:53Z" >> lat="-38.3731688" lon="144.844255"/> >> <node id="172751478" timestamp="2009-02-25T17:02:53Z" >> lat="-38.3731688" lon="144.8432851"/> >> >> <way id="16711763" timestamp="2009-02-25T17:02:53Z"> >> <nd ref="172752298"/> >> <nd ref="172751478"/> >> <nd ref="172752298"/> >> <tag k="created_by" v="Potlatch 0.5d"/> >> <tag k="leisure" v="park"/> >> </way> >> >> >> Regards, >> Josh >> >> >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Pymag-devel mailing list >> Pym...@li... >> https://lists.sourceforge.net/lists/listinfo/pymag-devel >> > > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Pymag-devel mailing list > Pym...@li... > https://lists.sourceforge.net/lists/listinfo/pymag-devel > |
|
From: Josh <jo...@fe...> - 2009-05-19 11:06:45
|
Oops, I had another think about that, and realised a 3 pointed closed polygon is actually more like a straight line ;) Is it possible to just discard bad polygons, seeing as they don't render anyway, and just break the map? Josh Quoting jo...@fe...: > I've just tried the latest code from svn, with mixed results. Some of > my maps have polygons rendering again, but others that warn about > Improper polygons now crash Mapsend/Vantagepoint. > > Some of the warnings I can understand - polygons with only 2 points, > or polygons that are 'open', but one example I saw has me confused... > > I got this warning one one tonight - > WARNING Improper polygon found: [(144.844255, -38.373168800000002), > (144.8432851, -38.373168800000002), (144.844255, -38.373168800000002)] > That shows a polygon with 3 points, and two of them have the same > coordinates? That should be a valid polygon unless I'm missing > something. > > The nodes/way relating to that error are: > > <node id="172752298" timestamp="2009-02-25T17:02:53Z" > lat="-38.3731688" lon="144.844255"/> > <node id="172751478" timestamp="2009-02-25T17:02:53Z" > lat="-38.3731688" lon="144.8432851"/> > > <way id="16711763" timestamp="2009-02-25T17:02:53Z"> > <nd ref="172752298"/> > <nd ref="172751478"/> > <nd ref="172752298"/> > <tag k="created_by" v="Potlatch 0.5d"/> > <tag k="leisure" v="park"/> > </way> > > > Regards, > Josh > > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Pymag-devel mailing list > Pym...@li... > https://lists.sourceforge.net/lists/listinfo/pymag-devel > |
|
From: <jo...@fe...> - 2009-05-19 10:50:01
|
I've just tried the latest code from svn, with mixed results. Some of
my maps have polygons rendering again, but others that warn about
Improper polygons now crash Mapsend/Vantagepoint.
Some of the warnings I can understand - polygons with only 2 points,
or polygons that are 'open', but one example I saw has me confused...
I got this warning one one tonight -
WARNING Improper polygon found: [(144.844255, -38.373168800000002),
(144.8432851, -38.373168800000002), (144.844255, -38.373168800000002)]
That shows a polygon with 3 points, and two of them have the same
coordinates? That should be a valid polygon unless I'm missing
something.
The nodes/way relating to that error are:
<node id="172752298" timestamp="2009-02-25T17:02:53Z"
lat="-38.3731688" lon="144.844255"/>
<node id="172751478" timestamp="2009-02-25T17:02:53Z"
lat="-38.3731688" lon="144.8432851"/>
<way id="16711763" timestamp="2009-02-25T17:02:53Z">
<nd ref="172752298"/>
<nd ref="172751478"/>
<nd ref="172752298"/>
<tag k="created_by" v="Potlatch 0.5d"/>
<tag k="leisure" v="park"/>
</way>
Regards,
Josh
|
|
From: henrik j. <hen...@gm...> - 2009-05-19 05:43:52
|
Hi Ingo, I tried the files and I have the same problem and I have found the bug in CellElement.py when a polygon is created and it checks if it's a closed polygon or not. Sadly, Mapsend Lite crashes when I zoom around when I have the Parks rule active. With parks commented out in the rule file it works fine though. I haven't yet been able to track down the offending park. Regards, Henrik On 13/05/2009, Ingo Hornberger <lab...@go...> wrote: > Hi Henrik, > > I tried it again with the current trunk and assured that I had no > locally changed files. But sadly with the same result. > > For a test I tried to render bremen.osm, because it is the smallest of > our states in germany ;) > > I attached you both files. I created it with the following command: > > ./osmmag.py -v -n "bremen" -r data/osmmagrules.xml -o bremen.imi bremen.osm > > And just to make it clear: I "sourced" the "setup.sh" into my > environment before: > . setup.sh > > Best regards, > Ingo > > 2009/5/11 henrik johansson <hen...@gm...>: >> Hi Ingo, >> >> Strange problem. There are plenty of polygon rules in the default rule >> file like parks and buildings. And they work fine on my explorist. >> >> Do you get any polygons with the default rule file? >> >> If you like you can send the osm-file and rule file that doesn't work >> for you and I'll have a look. >> >> Best regards, >> >> Henrik >> >> 2009/5/6 Ingo Hornberger <in...@ni...>: >>> Hi! >>> >>> It's me again... And again with some problems :) >>> >>> At the moment I am trying to generate a more complete osmmagrules.xml >>> which should render nice maps for my eXplorist 500. The problem is >>> that I get only roads and tracks, but I'm unable to render polygons. >>> So I get no nice landscape ;) >>> >>> Is there a problem with that? If not I would be very pleased if >>> someone can give me an example: >>> A small osm extract with an XML file and probably also the result >>> *.imi would do it. >>> >>> Probably it's only a lack of documentation ;) >>> >>> Thanks and best regards, >>> Ingo >>> >>> ------------------------------------------------------------------------------ >>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your >>> production scanning environment may not be a perfect world - but thanks >>> to >>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK >>> i700 >>> Series Scanner you'll get full speed at 300 dpi even with all image >>> processing features enabled. http://p.sf.net/sfu/kodak-com >>> _______________________________________________ >>> Pymag-devel mailing list >>> Pym...@li... >>> https://lists.sourceforge.net/lists/listinfo/pymag-devel >>> >> > |
|
From: Ingo H. <lab...@go...> - 2009-05-13 17:25:58
|
Hi Henrik, I tried it again with the current trunk and assured that I had no locally changed files. But sadly with the same result. For a test I tried to render bremen.osm, because it is the smallest of our states in germany ;) I attached you both files. I created it with the following command: ./osmmag.py -v -n "bremen" -r data/osmmagrules.xml -o bremen.imi bremen.osm And just to make it clear: I "sourced" the "setup.sh" into my environment before: . setup.sh Best regards, Ingo 2009/5/11 henrik johansson <hen...@gm...>: > Hi Ingo, > > Strange problem. There are plenty of polygon rules in the default rule > file like parks and buildings. And they work fine on my explorist. > > Do you get any polygons with the default rule file? > > If you like you can send the osm-file and rule file that doesn't work > for you and I'll have a look. > > Best regards, > > Henrik > > 2009/5/6 Ingo Hornberger <in...@ni...>: >> Hi! >> >> It's me again... And again with some problems :) >> >> At the moment I am trying to generate a more complete osmmagrules.xml >> which should render nice maps for my eXplorist 500. The problem is >> that I get only roads and tracks, but I'm unable to render polygons. >> So I get no nice landscape ;) >> >> Is there a problem with that? If not I would be very pleased if >> someone can give me an example: >> A small osm extract with an XML file and probably also the result >> *.imi would do it. >> >> Probably it's only a lack of documentation ;) >> >> Thanks and best regards, >> Ingo >> >> ------------------------------------------------------------------------------ >> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your >> production scanning environment may not be a perfect world - but thanks to >> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 >> Series Scanner you'll get full speed at 300 dpi even with all image >> processing features enabled. http://p.sf.net/sfu/kodak-com >> _______________________________________________ >> Pymag-devel mailing list >> Pym...@li... >> https://lists.sourceforge.net/lists/listinfo/pymag-devel >> > |
|
From: henrik j. <hen...@gm...> - 2009-05-11 13:02:33
|
Hi Ingo, Strange problem. There are plenty of polygon rules in the default rule file like parks and buildings. And they work fine on my explorist. Do you get any polygons with the default rule file? If you like you can send the osm-file and rule file that doesn't work for you and I'll have a look. Best regards, Henrik 2009/5/6 Ingo Hornberger <in...@ni...>: > Hi! > > It's me again... And again with some problems :) > > At the moment I am trying to generate a more complete osmmagrules.xml > which should render nice maps for my eXplorist 500. The problem is > that I get only roads and tracks, but I'm unable to render polygons. > So I get no nice landscape ;) > > Is there a problem with that? If not I would be very pleased if > someone can give me an example: > A small osm extract with an XML file and probably also the result > *.imi would do it. > > Probably it's only a lack of documentation ;) > > Thanks and best regards, > Ingo > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Pymag-devel mailing list > Pym...@li... > https://lists.sourceforge.net/lists/listinfo/pymag-devel > |
|
From: Ingo H. <in...@ni...> - 2009-05-06 15:34:43
|
Hi! It's me again... And again with some problems :) At the moment I am trying to generate a more complete osmmagrules.xml which should render nice maps for my eXplorist 500. The problem is that I get only roads and tracks, but I'm unable to render polygons. So I get no nice landscape ;) Is there a problem with that? If not I would be very pleased if someone can give me an example: A small osm extract with an XML file and probably also the result *.imi would do it. Probably it's only a lack of documentation ;) Thanks and best regards, Ingo |
|
From: henrik j. <hen...@gm...> - 2008-12-18 06:38:40
|
Hi, I have now added a check for this case and if a referenced node is undefined the node will simply be ignored with a warning message printed. /Henrik 2008/12/16 Josh <jo...@fe...> > Hi Ingo, > > The problem is with that OSM extract you're using. > It has 103 non-existent nodes still referenced in ways. One of them > you'll recognize from your error message - node 25884869. > I wrote a quick filter when I first played with pymag to clean up my OSM > dumps to stop this error, but I think it should be handled by pymag, by > just exclude any references to deleted nodes. > > The missing nodes are: > 104572522 > 142395382 > 170734405 > 170734407 > 170734408 > 170734409 > 170734410 > 170734412 > 170734413 > 170734415 > 170734417 > 170734418 > 170734419 > 170734421 > 170734422 > 170734424 > 170734425 > 170734426 > 170734427 > 170734429 > 170734430 > 170734431 > 170734433 > 170734435 > 246972078 > 246972079 > 246972080 > 246972081 > 246972083 > 246972084 > 246972086 > 246972087 > 246972088 > 246972089 > 246972090 > 246972091 > 246972092 > 246972093 > 246972094 > 246972095 > 246972096 > 248757745 > 252151160 > 252151161 > 252151162 > 252151163 > 252151164 > 252151165 > 252151166 > 252151167 > 252151168 > 252151169 > 254340837 > 254340867 > 25776570 > 25884869 > 25885322 > 25885335 > 25885661 > 25885662 > 258981333 > 258981334 > 258981335 > 258981336 > 258981337 > 259412603 > 259412604 > 25952823 > 25952839 > 267664509 > 59942013 > 59964349 > 59964350 > 59964351 > 59964352 > 59964353 > 59964354 > 60701473 > 60701474 > 60701475 > 60701476 > 60701477 > 60701478 > 60701479 > 60701480 > 60701481 > 60701482 > 60701483 > 60701484 > 60701485 > 60701486 > 60701487 > 60701536 > 60701537 > 60701538 > 60701539 > 60701540 > 60701541 > 60701542 > 60701588 > 60701589 > 60701615 > 68406202 > > > Cheers, > Josh > > > Ingo Hornberger wrote: > > Hi! > > > > First of all, thanks for your effort so far! This is currently the > > only practical abbroach for converting OSM's for our Magellan devices. > > > > I'm not yet on the list. And I also don't know Python at all. So I'm > > unable to do further debugging ATM. I used the OSM extracts from the > > following source: > > http://debian.mcmillan.net.nz/nzosm/ > > > > cellelement = CellElementPolyline([self.nodes[ref] for ref in > > self.waynodes], > > KeyError: 25884869 > > > > Best regards, > > Ingo > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Pymag-devel mailing list > Pym...@li... > https://lists.sourceforge.net/lists/listinfo/pymag-devel > |
|
From: Josh <jo...@fe...> - 2008-12-18 06:16:53
|
Hi Ingo, The problem is with that OSM extract you're using. It has 103 non-existent nodes still referenced in ways. One of them you'll recognize from your error message - node 25884869. I wrote a quick filter when I first played with pymag to clean up my OSM dumps to stop this error, but I think it should be handled by pymag, by just exclude any references to deleted nodes. The missing nodes are: 104572522 142395382 170734405 170734407 170734408 170734409 170734410 170734412 170734413 170734415 170734417 170734418 170734419 170734421 170734422 170734424 170734425 170734426 170734427 170734429 170734430 170734431 170734433 170734435 246972078 246972079 246972080 246972081 246972083 246972084 246972086 246972087 246972088 246972089 246972090 246972091 246972092 246972093 246972094 246972095 246972096 248757745 252151160 252151161 252151162 252151163 252151164 252151165 252151166 252151167 252151168 252151169 254340837 254340867 25776570 25884869 25885322 25885335 25885661 25885662 258981333 258981334 258981335 258981336 258981337 259412603 259412604 25952823 25952839 267664509 59942013 59964349 59964350 59964351 59964352 59964353 59964354 60701473 60701474 60701475 60701476 60701477 60701478 60701479 60701480 60701481 60701482 60701483 60701484 60701485 60701486 60701487 60701536 60701537 60701538 60701539 60701540 60701541 60701542 60701588 60701589 60701615 68406202 Cheers, Josh Ingo Hornberger wrote: > Hi! > > First of all, thanks for your effort so far! This is currently the > only practical abbroach for converting OSM's for our Magellan devices. > > I'm not yet on the list. And I also don't know Python at all. So I'm > unable to do further debugging ATM. I used the OSM extracts from the > following source: > http://debian.mcmillan.net.nz/nzosm/ > > cellelement = CellElementPolyline([self.nodes[ref] for ref in > self.waynodes], > KeyError: 25884869 > > Best regards, > Ingo > ------------------------------------------------------------------------ |
|
From: Ingo H. <lab...@go...> - 2008-12-16 12:28:21
|
Thanks! I just wanted to give you some feedback. In the meanwhile I already successfully converted the newer NZ maps which where divided into North- and South-Island. But I recognized that the whole Island is not very good integrated into OSM. Probably I can improve that with my Tracks after my trip to there ;) Thanks alot for all your effort so far! I hope that you will get routing working soon ;) Regards, Ingo 2008/12/16 Josh <jo...@fe...> > Hi Ingo, > > The problem is with that OSM extract you're using. > It has 103 non-existent nodes still referenced in ways. One of them you'll > recognize from your error message - node 25884869. > I wrote a quick filter when I first played with pymag to clean up my OSM > dumps to stop this error, but I think it should be handled by pymag, by just > exclude any references to deleted nodes. > > The missing nodes are: > 104572522 > 142395382 > 170734405 > 170734407 > 170734408 > 170734409 > 170734410 > 170734412 > 170734413 > 170734415 > 170734417 > 170734418 > 170734419 > 170734421 > 170734422 > 170734424 > 170734425 > 170734426 > 170734427 > 170734429 > 170734430 > 170734431 > 170734433 > 170734435 > 246972078 > 246972079 > 246972080 > 246972081 > 246972083 > 246972084 > 246972086 > 246972087 > 246972088 > 246972089 > 246972090 > 246972091 > 246972092 > 246972093 > 246972094 > 246972095 > 246972096 > 248757745 > 252151160 > 252151161 > 252151162 > 252151163 > 252151164 > 252151165 > 252151166 > 252151167 > 252151168 > 252151169 > 254340837 > 254340867 > 25776570 > 25884869 > 25885322 > 25885335 > 25885661 > 25885662 > 258981333 > 258981334 > 258981335 > 258981336 > 258981337 > 259412603 > 259412604 > 25952823 > 25952839 > 267664509 > 59942013 > 59964349 > 59964350 > 59964351 > 59964352 > 59964353 > 59964354 > 60701473 > 60701474 > 60701475 > 60701476 > 60701477 > 60701478 > 60701479 > 60701480 > 60701481 > 60701482 > 60701483 > 60701484 > 60701485 > 60701486 > 60701487 > 60701536 > 60701537 > 60701538 > 60701539 > 60701540 > 60701541 > 60701542 > 60701588 > 60701589 > 60701615 > 68406202 > > > Cheers, > Josh > > > Ingo Hornberger wrote: > >> Hi! >> >> First of all, thanks for your effort so far! This is currently the only >> practical abbroach for converting OSM's for our Magellan devices. >> >> I'm not yet on the list. And I also don't know Python at all. So I'm >> unable to do further debugging ATM. I used the OSM extracts from the >> following source: >> http://debian.mcmillan.net.nz/nzosm/ >> >> cellelement = CellElementPolyline([self.nodes[ref] for ref in >> self.waynodes], >> KeyError: 25884869 >> >> Best regards, >> Ingo >> ------------------------------------------------------------------------ >> > |
|
From: Ingo H. <in...@gm...> - 2008-12-14 14:31:13
|
Hi! First of all, thanks for your effort so far! This is currently the only practical abbroach for converting OSM's for our Magellan devices. I'm not yet on the list. And I also don't know Python at all. So I'm unable to do further debugging ATM. I used the OSM extracts from the following source: http://debian.mcmillan.net.nz/nzosm/ And I got the following errors: $ osmmag.py -v -n "New Zealand 20080607" -o New_Zealand-20080607-0503.imi -r ../../pakete/pymagellan-0.1/osmmagellan/data/osmmagrules.xml New_Zealand-20080607-0503.osm INFO Loading rules: ../../pakete/pymagellan-0.1/osmmagellan/data/osmmagrules.xml INFO Reading osm data and creating map Traceback (most recent call last): File "/usr/bin/osmmag.py", line 180, in ? main() File "/usr/bin/osmmag.py", line 176, in main bigendian=options.bigendian File "/usr/bin/osmmag.py", line 54, in osmmag data = osm.LoadOsm(osmfile, rules, m, nametags = nametaglist) File "/usr/lib/python2.4/site-packages/osmmagellan/osm.py", line 45, in __init__ self.loadOsm(filename) File "/usr/lib/python2.4/site-packages/osmmagellan/osm.py", line 56, in loadOsm parser.parse(filename) File "xml/sax/expatreader.py", line 107, in parse File "xml/sax/xmlreader.py", line 123, in parse File "xml/sax/expatreader.py", line 207, in feed File "xml/sax/expatreader.py", line 303, in end_element File "/usr/lib/python2.4/site-packages/osmmagellan/osm.py", line 104, in endElement cellelement = CellElementPolyline([self.nodes[ref] for ref in self.waynodes], KeyError: 25884869 Best regards, Ingo |
