Making it available as a jar #1
Comments
|
Would love to use this if it were distributed via Maven |
|
I'm the author. If either of you want to set up Maven and distribute it as a .jar, you can issue a pull request or contact me on: [email protected] I'm just unfamiliar with Maven. |
|
@drtimcooper Could you outline the build process for me? i.e. what is the input file and what gets called in what order to turn it into java code -Moody |
|
The input is “…/JsonPolygons/timezones.json” which is stored in the git repository. This in turn is produced by some C++ software from a .dbf file, but I haven’t updated that for several years – I recommend you don’t attempt to reconvert at that level. You run TimeZoneMapperConverter.main() as a Java program using commandline parameters of that input file and the output file without extensions. This will produce java, C# and Swift source files. I hope you have a Java IDE. But in theory you don’t need to run any conversion software…only to wrap up the existing TimezoneMapper.java file into a .jar that’s available to Maven. I can’t help you with that because I rely on my colleagues for Maven configuration and other configuration stuff. You can email me directly on [email protected] - it might get you quicker responses. From: Moody Salem [mailto:[email protected]] @drtimcooper https://github.com/drtimcooper Could you outline the build process for me? i.e. what is the input file and what gets called in what order to turn it into java code -Moody — |
|
I'm doing it in this repo I found a file with lat lngs and timezone strings, and it matches on 98% of them, which is good enough for me 👍 You can run |
|
Hi Moody: I looked at 3 examples of errors. Lustenau is right on the border between Austria and Switzerland. I’m not aiming for 10 metre accuracy so I’ll let that one slide. The time offsets don’t differ anyway. Patos Fshat in Albania is right in the middle of Albania so that would be a worrying error. However, when I reran the converter it fixed it up. This is a worry because I didn’t fix anything. I think I’ll just generally expand the list of test cases and hope that I can reconvert and find an error. Baikonur (Baykonyr) is in a district that also contains the city Qyzylorda, so I worry that in fact the authorities consider it to be in the Qyzylorda timezone. Those 2 polygons always have the same offset anyway so it’s all a moot point. Note also that I’m faithfully reproducing what the source polygons tell me. So I don’t really see any bug I can fix, except to release the reconverted source file. Let me know what your thoughts are about repositories before I do this. From: Moody Salem [mailto:[email protected]] I'm doing it in this repo https://github.com/moodysalem/LatLongToTimezoneMaven I found a file with lat lngs and timezone strings, and it matches on 98% of them, which is good enough for me Image removed by sender. 👍 You can run mvn test on that repo to see where it's failing. I'll deploy the repo to central soon enough. I'm going to add you as a collaborator and a developer in the pom Mar 24, 2016 4:41:53 PM com.moodysalem.TimeZoneMapperTest runTestCases |
|
Hi, I agree with Tim, the best would be to have only one repo. Moody's work is good, and more exhaustive than my PR. I guess the guess whould be to build another PR, with his pom. I'll see if I can find time to do that (My agenda is pretty full this week). Regards, |
|
Hello, I created a new PR : #6 |
|
It seemed clunky to me having a module in multiple languages in the same repository-if they were different branches they would likely never merge except to sync the source shapefiles I think the ideal maintenance structure is one repository generates some easily consumable intermediate format, and then each of the respective consumers (swift, java, c#) load the file into a tree used to decode lat/lngs |
|
@moodysalem @drtimcooper Thanks for doing this. I wanted to choose whether to use Java file directly from this repo, or the library prepared here so I checked the accuracy. I'm surprised that the maven lib v 1.2 seems to be more accurate (it triggered less errors on my dataset), and yet the library was last released in Feb 2017, and the java file was modified recently (Mar 2019). Why is that? Does the maven version build it's own implementation based on some other dataset / in different more precise way? |
|
@darpandhamija : Can you answer maraswona's question? I am having difficulty finding time to keep up-to-date with this project. |
|
@maraswrona The maven version is not modified in any way from this repo, I expect if you get the Feb 2017 version from this repo the results will be identical |
|
@moodysalem The exact source code used by your library is this: https://raw.githubusercontent.com/moodysalem/LatLongToTimezoneMaven/master/src/main/java/com/moodysalem/TimezoneMapper.java What makes me wonder is why is the newer implementation from this repository causing some weird errors which don't occur in previous implementation (and also don't occur in yours)? Here are the example differences I mentioned before (TimeZoneMapper local is recent source from this repo, jar is from the recent maven version, geonames is for reference):
Also I think it would be much less confusing if you guys could merge your work into single repository, releasable to maven automaticaly upon merge etc. It's really confusing having this code duplicated between repositories, with different implementations between the maven version and plain source code version. |
|
@maraswrona What are some weird errors you are experiencing? The difference in result is because, jar is not based on latest data. I updated the data for the local TimeZoneMapper.java based on https://github.com/evansiroky/timezone-boundary-builder/releases 2018i release whereas jar is based on an older version. I believe, since timezone data since has changed as has the results you are getting. |
|
I listed the errors above. Basically some locations in Poland are identified as Stockholm timezone (instead of Warsaw). These aren't very close to the border so it's not really an issue of +/-100m accuracy, like I have seen with other locations (e.g. points very close to the land border are tricky, understandable). These locations are several km from the shore. And hundreds of km from actual Sweden. |
|
Hi MoodySalem:
Would it help if I gave you admin rights over the main github repository?
From: maraswrona <[email protected]>
Sent: Wednesday, 27 March 2019 9:25 PM
To: drtimcooper/LatLongToTimezone <[email protected]>
Cc: Tim Cooper <[email protected]>; Mention <[email protected]>
Subject: Re: [drtimcooper/LatLongToTimezone] Making it available as a jar (#1)
@moodysalem <https://github.com/moodysalem> The exact source code used by your library is this: https://raw.githubusercontent.com/moodysalem/LatLongToTimezoneMaven/master/src/main/java/com/moodysalem/TimezoneMapper.java
The same class from this repository from the corresponding timeline is this: https://raw.githubusercontent.com/drtimcooper/LatLongToTimezone/2904b9210102afdb0093d418c714cdd4d3e0c544/src/main/java/com/skedgo/converter/TimezoneMapper.java
I have run a diff on both files and they are not identical. I have also checked my dataset against both implementations and this time differences were gone (even though files are not identical).
What makes me wonder is why is the newer implementation from this repository causing some weird errors which don't occur in previous implementation (and also don't occur in yours)?
Here are the example differences I mentioned before (TimeZoneMapper local is recent source from this repo, jar is from the recent maven version, geonames is for reference):
TimeZoneMapper local
TimeZoneMapper jar
geonames reference
country
city
lat lng
Europe/Stockholm
Europe/Warsaw
Europe/Warsaw
Poland
Koszalin
54.193986 16.172544
Europe/Prague
Europe/Warsaw
Europe/Warsaw
Poland
Owsiszcze
49.9762 18.220037
Europe/Stockholm
Europe/Warsaw
Europe/Warsaw
Poland
Karlino
54.033463 15.876462
Europe/Stockholm
Europe/Warsaw
Europe/Warsaw
Poland
Koszalin
54.190323 16.19931
Europe/Stockholm
Europe/Warsaw
Europe/Warsaw
Poland
Bobolice
53.954554 16.585088
Europe/Stockholm
Europe/Warsaw
Europe/Warsaw
Poland
Karlino
54.033463 15.876462
Europe/Stockholm
Europe/Warsaw
Europe/Warsaw
Poland
Kołobrzeg
54.17688 15.577563999999999
Europe/Stockholm
Europe/Warsaw
Europe/Warsaw
Poland
Ustronie Morskie
54.214228999999996 15.75728
Europe/Stockholm
Europe/Warsaw
Europe/Warsaw
Poland
Koszalin
54.210871999999995 16.198394
Europe/Prague
Europe/Warsaw
Europe/Warsaw
Poland
Owsiszcze
49.9762 18.220036999999998
Europe/Stockholm
Europe/Warsaw
Europe/Warsaw
Poland
Białogard
54.016310999999995 15.961533
Europe/Stockholm
Europe/Warsaw
Europe/Warsaw
Poland
Białogard
54.004995 15.990838
Also I think it would be much less confusing if you guys could merge your work into single repository, releasable to maven automaticaly upon merge etc. It's really confusing having this code duplicated between repositories, with different implementations between the maven version and plain source code version.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4IF5nDB-M9fZBGlZEYirGWr2ouUrzyks5va0cVgaJpZM4G8Uzq> . <https://github.com/notifications/beacon/AB4IF9e6pZ2WhCkKN0Hlh1MWEofsLmf3ks5va0cVgaJpZM4G8Uzq.gif>
|
|
i see PR-6, to mavenize this project - great work @rlemaire ! |
Hello,
Is it planned to make the java files available in a jar ?
Thank you.
The text was updated successfully, but these errors were encountered: