Broken OSM import

vaxvax Global Mapper UserPosts: 123Trusted User
edited January 2014 in Technical Support
Hello Mike,

I tried to import/export in OSM format some point-data with custom attributes/values.

It seems that GM exports correctly point data, but when trying to import the OSM file back, it refuses to do so with - "No data with recognized OSM types could be loaded ..."

It seems that there is an active OSM type filter similar to the OGR/GDAL plugin but I cannot find out where to configure it.

My question is if it is possible to export/import ANY type of OSM objects as in the current implementation it is quite uncertain what exactly will be imported and exported. GM version is 13.2.

Best regards,


  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited January 2014

    I'm not sure how I didn't see this message, I apologize for not responding sooner.

    Can you try your process in a trial of Global Mapper v15 from Global Mapper Downloads and see if you get the same issue?

    If you have your point features set up with a type that causes it to be a recognized OSM type then the re-import should keep it rather than discarding the node. For example, if the point has an attribute with any of the following names and any value, it should be kept:


    There will be automatic assignment of some those attributes for some built-in Global Mapper types, like city points, buildings, etc.


    Global Mapper Guru
    Blue Marble Geographics for Coordinate Conversion, Image Reprojection and Vector Translation
  • vaxvax Global Mapper User Posts: 123Trusted User
    edited January 2014
    Hi Mike,

    thanks for the hint. The points that fail this way have attributes


    and some custom .MP format-derived attributes as MP_TYPE, etc.

    My opinion is that no point should be rejected on import. There are still hundreds of different possible attributes that lay outside the attribute set you listed above. Also objects with new/custom attributes (possible in OSM) are not supported.

    Anyway if we want to stay within the tight set you mentioned above, maybe it's a good idea to have an import switch that can control if we read objects only within a specific attribute set, or read all objects with ANY set of attributes (which is actually what I need).

    P.S. I just saw another problem - attributes with values in cyrillic script are shown mangled in another charset.
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited January 2014
    The problem is that the OSM XML stores any kind of interesting point between lines as a <node> which is also how actual point features are stored. You don't want separate point features for every <node> since many don't actually represent anything, so to avoid littering the map with a bunch of point features there is logic to see if a <node> actually appears to be a feature. That logic is quite old and was based on the original OSM type system though, so perhaps that can be improved.

    Can you provide a sample file where some of the points aren't coming in and I will take a look and see if I can loosen things up a bit?

    For the Cyrillic text, the problem is that Global Mapper doesn't support full Unicode display, so text is stored as multi-byte text and will typically only display correctly if the text is in the current code page of the system. So on a system set to use the Russian language and with the display character set to Cyrillic it would be ok, but on a system set to some other language it would look like garbage.


    Global Mapper Guru
    Blue Marble Geographics for Coordinate Conversion, Image Reprojection and Vector Translation
Sign In or Register to comment.