-
Notifications
You must be signed in to change notification settings - Fork 218
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
Thousands of exceptions when parsing a geometry object #2013
Comments
Hi nassif, could you share the data that trigger this errors?
Il giorno mar 5 dic 2023 alle ore 16:17 Luis Filipe Nassif <
***@***.***> ha scritto:
… Processing a 150GB UFDR with master, 50950 exceptions like below were
printed in the processing log:
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed linestring
at com.vividsolutions.jts.geom.LinearRing.validateConstruction(LinearRing.java:111)
at com.vividsolutions.jts.geom.LinearRing.<init>(LinearRing.java:106)
at com.vividsolutions.jts.geom.GeometryFactory.createLinearRing(GeometryFactory.java:355)
at com.vividsolutions.jts.geom.GeometryFactory.createLinearRing(GeometryFactory.java:342)
at iped.geo.parsers.kmlstore.KMLParser.parseGeometry(KMLParser.java:236)
at iped.geo.parsers.kmlstore.KMLParser.parseGeometry(KMLParser.java:256)
at iped.geo.parsers.kmlstore.KMLParser.parsePlacemark(KMLParser.java:157)
at iped.geo.parsers.kmlstore.KMLParser.parse(KMLParser.java:64)
at iped.geo.parsers.kmlstore.KMLFeatureListFactory.parseFeatureList(KMLFeatureListFactory.java:12)
at iped.geo.parsers.GeofileParser.parse(GeofileParser.java:76)
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:298)
at iped.parsers.standard.StandardParser.parse(StandardParser.java:245)
at iped.engine.io.ParsingReader$BackgroundParsing.run(ParsingReader.java:247)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Not sure if it is a bug or just a corrupted geometry object, at least I
think above logging should be less verbose.
—
Reply to this email directly, view it on GitHub
<#2013>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG247S64DMT5GIUGH6L36SDYH56MVAVCNFSM6AAAAABAIIUYJWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGAZDOMBVGQ2TGMA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Sure, I'll try to find a triggering file tomorrow. |
Hi @patrickdalla, I found the case triggering this, just sent the KML samples to you by Teams. |
Many of the exceptions are of type "Points of LinearRing do not form a closed linestring". So, I suggest 2 options (or both):
I think the second is necessary. What about the first? Should IPED try to recover it? |
I saw that in some files were defined "linearring" 's with 2 coords only, what leads to another exception, that a linearring needs at least 4 coords (even if we add the first coord as the last). So another solution would to create "linestring" objects from these invalid linearring entries. Does it seem a good method to bypass these invalid entries? |
represents unclosed linearring features as linearstring.
Some other syntax/semantics errors to bypass or correct:
|
I agree to 2. Closing an open linear ring could lead to wrong conclusions, as you noticed. If converting them to a "linear string" is simple and don't take too much processing time, that's seems a good approach. |
Processing a 150GB UFDR with master, 50950 exceptions like below were printed in the processing log:
Not sure if it is a bug or just a corrupted geometry object, at least I think above logging should be less verbose.
The text was updated successfully, but these errors were encountered: