Hi,

I have been playing around with FME Desktop for a great while now and I think it's definitely capable, however, my knowledge lacks a bit here.

I am trying to convert an OSM XML (Luxembourg for example, but not limited to) into a couple of information levels:

• level 0
  • point (equals nodes)
    • xyz id (equal to node id)
    • node id/index
    • Face id
  • line (equals edges)
    • xyz id
    • edge id/index
    • from node id
    • to node id
    • left face id
    • right face id
  • polygon (equals faces)
    • face id/index
    • edges{}.edge_id
    • edges{}.orient (boolean value of all_edges{edge_id}.fknot > all_edges{edge_id}.tknot)
• level 1
  • point (equals nodes)
    • point id (this correlates with the level_0 point id of this point)
    • desc id (type parameter, maps to an array of strings)
    • feature code (an integer, which maps to an array of strings)
    • attributes{}.segmented_attr_id
    • nodes{}.node_id (all the level_0_points that are connected to this point)
  • line (equals edges)
    • line id (correlates with level_0_line id of this line)
    • desc id (type parameter, maps to an array of strings)
    • feature code (an integer, which maps to an array of strings)
    • split_ind (split in direction?)
    • from id (node id)
    • to id (node id)
    • attributes{}.segmented_attr_id
    • edges{}.edge_id
    • edges{}.pos_neg (I guess that this is if the direction goes up or down)
  • polygon (equals faces)
    • area id
    • desc id (type parameter, maps to an array of strings)
    • feature code (an integer, which maps to an array of strings)
    • split_ind (split in direction?)
    • attributes{}.segmented_attr_id
    • faces{}.face_id (all the faces that are connected to this feature)
• level 2 ( I do not have proper documentation for this level, https://docs.safe.com/fme/2017.1/html/FME_Desktop_Documentation/FME_ReadersWriters/gdf/level_2_point.htm)
  • point
    • comf_id (?)
    • desc id (type parameter, maps to an array of strings)
    • feature code (an integer, which maps to an array of strings)
    • split ind (split in direction?)
    • attributes{}.segmented_attr_id
    • parts{}.feat_id
    • parts{}.feat_cat
  • line
    • comf_id
    • desc id (type parameter, maps to an array of strings)
    • feature code (an integer, which maps to an array of strings)
    • split ind (split in direction?)
    • from id (same as level_0_line and level_1_line)
    • to id (same as level_0_line and level_1_line)
    • attributes{}.segmented_attr_id
    • parts{}.feat_id
    • parts{}.feat_cat
  • polygon
    • comf_id (?)
    • desc id (type parameter, maps to an array of strings)
    • feature code (an integer, which maps to an array of strings)
    • split ind (split in direction?)
    • attributes{}.segmented_attr_id
    • parts{}.feat_id
    • parts{}.feat_cat

Up until now I've been using a 'highway' reader followed by an intersector followed by a TopologyBuilder; to get all the edges, points and polygons.

The outputs of the TopologyBuilder are connected to the level_0 and level_1 features respectively and data did come out.

That has worked fine, but last night I was thinking about the process again.

The OSM data, already contains node id's for each node on a line, so there is no need to process every line again and break them up into points. I've inspected the output data and there are more nodes than in the original data file (not to mention the missing attributes, like not permitted to turn right, or roads that cross each other with bridges)

My question therefore is:

How do I process the OSM XML dataset in such a way that the original nodes, faces and edges are preserved (but renumbered with 32-bit id's), including their data attributes. Basically I want to have the output dataset of the TopologyBuilder, but without building the topology.

Also; as mentioned some attributes of a feature are mapped to integers (32-bit) or shortened strings (like 2 chars), that represent a specific value, the mapping between the two are known, need to be written to the writer output and need to be used to write the data properly. I've got the feeling that this might have something to do with schema's of some sort.

I do have an example GDF file that you can mess around with (make sure to turn Ignore Header Metadata Records on).

This project will be open-source once it's finished and is meant to preserve some of computer software's history by still being able to provide the rather old GDF 3.0 file format generated from recent OSM XML files.

If you've got any questions, feel free to ask them!

Tim