You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Upon initial review, it LOOKS like the facility has reversed Beginning/Ending LAT/LON values however to be sure, we need the .GeoMap for ZKC and their files are protected behind their website login. Message sent to the ZKC DATM Chris Raabe on 10AUG2023 and awaiting response.
#151 - Sounds like the source file coords are reversed. just from looking at the output file from FE buddy. I would need the source file before I am comfortable writing code to fix this issue.
Additional comments to prepare for adding defaults to the geojson output.
I took a look at your vERAM files and I see why they are so bulky… they have a reversed “flow” of coordinates from normal.
If a line string goes from point 1 to 2 to 3 and to 4…. They normally draw it like this in the file: 1-2… 2-3… 3-4
but ZKCs does this a significant amount of the time: 2-1… 3-2… 4-3
FE-Buddy thinks that since the starting coordinate does not match the previous ending coordinate, that you want to BREAK the line here and begin a new one. With GeoJSONs, this means making a completely new Feature and will result in EVERY line having its own feature. This creates massive GeoJSON files.
Though, we are brainstorming ideas for how to resolve this with FE-Buddy, it is unlikely to happen, at least anytime soon so, if ZKC are having problems with bulky GeoJSONs, they may need to consider finding a way reformat it to: 1-2… 2-3… 3-4.
Describe the bug
See ZKC's map attached below, which has only two point LineStrings
To Reproduce
Steps to reproduce the behavior:
1.
2.
3.
4.
Expected behavior
Screenshots
If applicable, add screenshots to help explain your problem.
The text was updated successfully, but these errors were encountered: