closed ways

Mar 23, 2011 at 12:58 AM


I found a little bug in the fileLoader.

OSM ways having the same node for start and end are usually interpreted as polygons except some keytags like "higway" are present. If one of those is present the way is supposed to be a closed line feature but the converted feature misses the connection of the first node and the one previous to the last.

You can check it out by loading this part of the osmxml file where this behaviour occurs:

  <node id='1082116657' lat='50.0349005' lon='8.3560952' user='JND' timestamp='2011-01-04T14:17:16Z' uid='43824' version='1' changeset='6861061'>
  <node id='1082116659' lat='50.0346731' lon='8.3561382' user='JND' timestamp='2011-01-04T14:17:16Z' uid='43824' version='1' changeset='6861061'>
  <node id='1082116662' lat='50.0344043' lon='8.3566531' user='JND' timestamp='2011-01-04T14:17:16Z' uid='43824' version='1' changeset='6861061'>
  <node id='1082116664' lat='50.0343699' lon='8.3567497' user='JND' timestamp='2011-01-04T14:17:16Z' uid='43824' version='1' changeset='6861061'>
  <node id='1082116667' lat='50.0345697' lon='8.3570608' user='JND' timestamp='2011-01-04T14:17:16Z' uid='43824' version='1' changeset='6861061'>
  <node id='1082116669' lat='50.0347765' lon='8.3570394' user='JND' timestamp='2011-01-04T14:17:16Z' uid='43824' version='1' changeset='6861061'>
  <node id='1082116673' lat='50.0348867' lon='8.3567926' user='JND' timestamp='2011-01-04T14:17:16Z' uid='43824' version='1' changeset='6861061'>
  <node id='1082116674' lat='50.0350383' lon='8.3565244' user='JND' timestamp='2011-01-04T14:17:16Z' uid='43824' version='1' changeset='6861061'>
  <node id='1082116676' lat='50.0352175' lon='8.3568033' user='JND' timestamp='2011-01-04T14:17:16Z' uid='43824' version='1' changeset='6861061'>
  <node id='1082116684' lat='50.0353485' lon='8.3565459' user='JND' timestamp='2011-01-04T14:17:17Z' uid='43824' version='1' changeset='6861061'>
  <node id='1082116629' lat='50.0350383' lon='8.355988' user='JND' timestamp='2011-01-04T14:17:15Z' uid='43824' version='1' changeset='6861061'>
  <way id='93331244' user='JND' uid='43824' timestamp='2011-01-04T14:17:17Z' version='1' changeset='6861061'>
    <nd ref='1082116657'/>
    <nd ref='1082116659'/>
    <nd ref='1082116662'/>
    <nd ref='1082116664'/>
    <nd ref='1082116667'/>
    <nd ref='1082116669'/>
    <nd ref='1082116673'/>
    <nd ref='1082116674'/>
    <nd ref='1082116676'/>
    <nd ref='1082116684'/>
    <nd ref='1082116629'/>
    <nd ref='1082116657'/>
    <tag k='access' v='private'/>
    <tag k='highway' v='service'/>

Will this be fixed in the next release? When might this be?

Could you provide a list of the keytags which decide that the closed way is interpreted as linefeature instead of polygon in FileLoader? this would be helpfull, because I wrote a little script to gather all attributes with statistics out of the xml file and want to prevent showing wrong attributes for the polygon featureclass.



Mar 23, 2011 at 9:22 AM


execellent find. It was indeed a bug and it is fixed now. I just posted an updated beta version that includes a number of other bug fixes as well.

There is no explicit keytag list to decide what is a line and what is a polygon. In OSMGPDownload.cs there is a method called IsThisWayALine. It assumes the following logic, if the first and last node in a way are the same then it is polygon unless it is has highway or a natural=coastline tag. If the way contains an explicit tag with area=yes then the way will be turned into a polygon irregardless of the closed way notation.

Thanks for your continuous feedback,




Mar 30, 2011 at 6:44 PM


thanks for the quick fix and release!


I don't know, if you are the right person to ask this, but I'll try. If not, never mind, I'd write it to esri-support then.

In my programm I use easygui for userinputs. When the arcpy module is imported a conflict between those two modules appears when calling easygui.choicebox(...) or easygui.multchoicebox(...) with a list longer then the guifield can show at once. Without importing arcpy, easygui works fine.

download easygui:  

the script has to get slightly modified: replace the two instances of "4.5i" with "10cm", then it works together with arcpy. Then copy it into the python2.6/lib/side-package folder

When you execute this script, you will see the conflict:

import easygui
import arcpy
posNameChar = ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q',
           'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z',
           'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q',
           'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z',
easygui.choicebox(msg='', title='', choices=(posNameChar))


Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python26\lib\lib-tk\", line 1410, in __call__
    return self.func(*args)
  File "C:\Python26\lib\lib-tk\", line 2813, in set, 'set') + args)
TclError: expected floating-point number but got "0,129032"


The number in the Traceback seems to be the position of the scrollbar, where somehow a comma has replaced the point. ???

Scrolling is still possible by mousewheel or keyboard. The scrollbar doesn't work which isn't a big Problem, but Its not nice to have Errormessages shown in the console all the time ;)

The developer of easygui assumes a Tkinter event-loop conflict as the root of this problem which supposedly goes deeper than the "4.5i" problem. But he doesn't have arcpy to check, if he is right and to develope a fix for easygui.

Do you have any ideas how to fix this or where the problem might be located and do you know if just importing arcpy opens an tkinter event-loop?





Apr 4, 2011 at 7:19 AM


please do go ahead with contacting support with issue.

I am afraid that I aggree with the developer of easygui (without having looked at the software package itself). A couple weeks ago we had holistic testing for new python functionality being introduced at 10.1. One of new things for the next release is that you can generate custom tools/command as add-ins using python and this capability does include some UI components. A lot of testers were looking for a more complete python UI integration but were unsuccessful to do so. The issue at hand is that python UI processes want to be the master process and ArcMap wants the same thing. We were told that a number of things can go wrong with the eventing loop and in the worst case one entity (either the python UI or ArcMap) will crash.

Please make your case known to the support team and have the issue trickle back to the core development team.




Apr 5, 2011 at 3:24 AM

Problem solved :)

import locale
locale.setlocale(locale.LC_ALL, 'english_us')

Ans every call of an arcpy funktion switches the locale back to german, so I have to set it back to US, if I want to use easygui again sometime afterwards in the code.

that makes it work fine now!