BGDIINF_SB-2610: enhance legacy kml import#297
Merged
Conversation
afb2ec8 to
8285919
Compare
Contributor
Contributor
Author
The check is made in "src/api/features.api.js" line 255 - 257 without the use of the metadata from the backend. It would surely be more robust to also check the metadata from the backend, but I think that this can be implemented when we also implement the check to make sure that old kmls are always read only, as I don't think that I have enough time this afternoon to do this. |
pakb
approved these changes
Nov 22, 2022
1a40222 to
a540de6
Compare
a540de6 to
94086ea
Compare
pakb
requested changes
Nov 23, 2022
Contributor
pakb
left a comment
There was a problem hiding this comment.
there's some issue with unit tests, seems like it is using axios or some other libs (that shouldn't happen while unit testing)
Plus the parsing of the old KML doesn't parse the icon color correctly, I'll investigate while @jedef is in vacations
Added a parser that can generate an editable feature from an olFeature that was just created from a KML file.
The old viewer now recognizes the feature types if it reads a kml file generated by the new viewer.
…wer. Parse the icon url format from the old viewer to recreate the editable feature. Also added some comments.
- Editable feature and ol feature now share the same id, so that it is not necessary to do string transformations to translate between the two. - When importing an old kml, the old id format is translated to the new id format when importing - Now the id is generated using a timestamp. This should reduce the chances of collision.
- set coordinates an id correctly on olFeature - added a new text size to be compatible with the old viewer - added documentation
Reversed the fix for backward compatibility, as it caused some issues and was not needed, as we only want to support forward compatibility.
Moving all legacy KML utils function into a dedicated file, also moving along related tests Removing the import of the store in the utils function and passing requirements as params instead Renaming Icon class into DrawingIcon (and DrawingIconSet instead of IconSet) in order not to mix match the name with OpenLayers Icon class Renaming default Feature class into SelectableFeature, same as above, so that it does not collide with OpenLayers Feature class (and having one word class name is a bad practice anyway)
94086ea to
22ae41d
Compare
pakb
approved these changes
Nov 29, 2022
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When importing a kml from mf-geoadmin3, the viewer is now able to reconstruct the editable feature based on the style infomration that is stored in the kml.
Test link