Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial support for multiple OSM imports #379

Merged
merged 3 commits into from
Mar 21, 2021
Merged

Conversation

craigtaverner
Copy link
Contributor

@craigtaverner craigtaverner commented Mar 21, 2021

Version 0.28 begins work on trying to deal work multiple OSM imports. For this release, we disallow importing the same OSM file twice, unless you specify two separate layers, and we also ensure that the indexes are not mixed up between the layers, something that was the case in all previous releases.

To achieve this, two main changes were made:

  • Use unique labels for indexing within multiple OSM layers.
    Essentially when adding nodes of a particular label, we also add a label with a unique name for indexing purposes.
    The unique name is made of the original name plus a hex suffix made of the MD5 hash of the layer name.
    For example, the layer geom1 will have an MD5 hash of its name 9ECE5459EA0D46FC556E5E3F454A0795.
    Then when adding an OSM node we label the node with both:

    • OSMNode
    • OSMNode_9ECE5459EA0D46FC556E5E3F454A0795
  • Remove use of old reference nodes, reducing deadlocks.
    This change is not backwards compatible, as the spatial model is different. Layers created in earlier versions would not be readable in this one.
    To protect against that we throw exceptions on all SpatialDatabaseService. layer finding methods, if they detect the old format. The exception requests that the database be upgraded.
    This can be done in the Java API with the upgradeFromOldModel method, or via procedures using spatial.upgrade.

Also add support for exception on trying to import the same OSM file twice, as this is not yet supported and will cause errors or model corruptions.

This change is not backwards compatible, as the spatial model is different. Layers created in earlier verions would not be readible in this one. To protect against that we throw exceptions on all SpatialDatabaseService. layer finding methods, if they detect the old format. The exception requests that the database be upgraded.

This can be done in the Java API with the upgradeFromOldModel method, or via procedures using `spatial.upgrade`.
Essentially when adding nodes of a particular label, we also add a label with a unique name for indexing purposes.
The unique name is made of the original name plus a hex suffix made of the MD5 hash of the layer name.

For example, the layer `geom1` will have an MD5 hash of its name `9ECE5459EA0D46FC556E5E3F454A0795`.
Then when adding an OSM node we label the node with both:

* OSMNode
* OSMNode_9ECE5459EA0D46FC556E5E3F454A0795

The second label is also used to create a label-property index to be used for looking up the node when building ways.
@craigtaverner craigtaverner merged commit 9131753 into master Mar 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant