Documentation for installing GeoSupport on Linux?

[chrismarx]

The readme says that "details are coming soon", I'm wondering if there are any basic pointers for where to put/setup the geosupport library. I tried to build geoclient, but I get:

"java.lang.IllegalArgumentException: Neither path nor baseDir may be null or empty string. path='null' basedir='/home/git/geoclient/geoclient-native"

I suspect this has something to do with it not finding geosupport?

[mlipper]

As you've guessed, this message is generated because Gradle chokes while trying to configure machine-specific paths for the build.

On the dev branch: I've added some additional info about building Geoclient to the README.md file. Time permitting, I'm planning to complete this section in the next day or two.

In meantime, please have a look at the comments in gradle.properties and gradle/env.gradle. Specifically, make sure you've set and exported the environment variables: GS_INCLUDE_PATH, GS_LIBRARY_PATH, GEOFILES, JAVA_HOME. Also, see the contents of the geoclient-native/etc folder and back-up and replace the original Geosupport headers as indicated.

Stay tuned and thanks for filing this issue.

[chrismarx]

Hi, thank you! Looks like I'm much closer now. I made the various additions, but I'm not sure what you mean by "replacing the original geosupport headers as indicated". I'm looking at the files in geoclient-native/etc and not seeing anything with instructions about that, unless maybe you're referring to this GLUEGEN issue? But I'm building for linux, so still not sure.

The build now fails at :

gov.nyc.doitt.gis.geoclient.config.GeosupportConfigIntegrationTest > classMethod FAILED
    java.lang.UnsatisfiedLinkError at GeosupportConfigIntegrationTest.java:47
136 tests completed, 1 failed
:geoclient-core:test FAILED

Also, I noticed what could be typos on the dev branch readme:

1. Set environment variable GS_INCLUDE_PATH=<geosupport install>/foruser/include this looks like it should be /include/foruser, at least for the master branch version
2. Specify the gsIncludePath property in the gradle.properties file in the base Geoclient source tree or on the command line as a Gradle project property -PgsIncludePath=<geosupport install>/lib - notice that the include path appears to be wrong here, it was just listed above as /foruser/include
3. The gradle.properties file at the geoclient root says that the variable "gcLibraryPath" shouldn't be set. Is this a different property from "gsLibraryPath" and if so, the new instructions say that you should set it?

[mlipper]

Thanks for pointing these errors out. I'll fix them.

Regarding the current build error: this is the Java runtime telling you it can't find the Geosupport and Geoclient shared libraries.

Geosupport's libraries for the Linux distribution are under the lib subdirectory in the root of the uncompressed download: lib/*.so. In the Geoclient build, the folder containing these files is specified with the GS_LIBRARY_PATH environment variable or the gsLibPath Gradle project property.

By default, after successfully running ./gradlew regenerate, Geoclient's libraries will be in build/libs. For Linux, the two you need are libgeoclient_jni.so and libgeoclient.so. In the Geoclient build, the folder containing these files is specified with the GC_LIBRARY_PATH environment variable or the gcLibPath Gradle project property. In past revisions, GC_LIBRARY_PATH environment variable or the gcLibPath Gradle project property was needed to specify when running the build. However, setting either will not cause problems but is no longer necessary.

The error you are seeing seems to indicate that Java doesn't know where to find the Geosupport and/or Geoclient libraries from above.

I'm redacting the rest of my original response because it is TMI and confusing to the solution for your issue.

[cm325]

Thank you for your patience and the fixes! I feel like I'm getting closer... now I'm stuck here:

version-16c_16.3/lib/libgeo.so: undefined reference toceil' /usr/local/lib/gdelx_16c/version-16c_16.3/lib/libgeo.so: undefined reference to sin' /usr/local/lib/gdelx_16c/version-16c_16.3/lib/libgeo.so: undefined reference toatan' /usr/local/lib/gdelx_16c/version-16c_16.3/lib/libgeo.so: undefined reference to tan' /usr/local/lib/gdelx_16c/version-16c_16.3/lib/libgeo.so: undefined reference tocos' /usr/local/lib/gdelx_16c/version-16c_16.3/lib/libgeo.so: undefined reference to log' /usr/local/lib/gdelx_16c/version-16c_16.3/lib/libgeo.so: undefined reference topow' /usr/local/lib/gdelx_16c/version-16c_16.3/lib/libgeo.so: undefined reference to sqrt' /usr/local/lib/gdelx_16c/version-16c_16.3/lib/libgeo.so: undefined reference tofloor' collect2: error: ld returned 1 exit status `

some kind of c++error? not sure where to go with this

[mlipper]

It looks as though the linker can't find a math library that's part of Linux systems (libm.so). I assume you're using Gradle to build (if you're not, please share the arguments you're using with gcc and the linker).

In the geoclient source, the file ${projectDir}/geoclient-native/build.gradle defines the flags passed to the linker when using Linux on line 75:

 linker.args "-L${gsLibraryPath}", "-lc", "-lm", "-lgeo", "-ledequiv", "-lapequiv", "-lsan", "-lsnd", "-lstExcpt", "-lStdLast", "-lStdUniv", "-lstEnder", "-lstretch", "-lthined"

The -L${gsLibraryPath} argument is the path to search (in addition to the default library path used by the linker and the path to the geoclient.o and geoclient_jni.o object files just built by gcc). The -l<libname> arguments that follow are the list of shared library files. ~~These are ordered such that libraries which have dependencies on other libraries appear after them in the list: ~~

```sh # libcat depends on both libmouse and libcheese # libmouse depends on libcheese ... -lcheese -lmouse ... -lcat ```

(BTW, a dependency between listed libraries isn't necessarily implied. The ordering matters only when such dependencies exist.)

Turns out my explanation is relevant only to certain gcc configurations and further obfuscated by the fact that the build relies on Gradle's algorthm for ordering of the separately specified compiler and linker args. Please see the following for more info:

• https://wiki.gentoo.org/wiki/Project:Quality_Assurance/As-needed#Importance_of_linking_order
• https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
• https://docs.gradle.org/current/userguide/native_software.html

Also, note that when Gradle chokes because the native compiler is angry that Gradle's error message to stdout specifies the location of a file preserving the actual command line it used to invoke gcc.

The naming conventions are such that -l<name> equates to a search on the library path for a file named lib<name>.so. On windows, using MSVC++ this would be <name>.dll. In the Gradle build, then, the -lm is telling the linker to search the library path for file libm.so which geo library (-lgeo) uses.

Can you run the build again with the -i flag and post the result? E.g., from the geoclient project root directory, run

$ ./gradlew -i regenerate > build.log 2>&1

Can you also please provide details on your Linux distro?

If none of the above makes any sense, feel free to contact me offline and we can talk on the phone for a few minutes which will be faster.

[jqnatividad]

Apologies for jumping into the thread, but @mlipper, can you share what distro you use internally? We favor Ubuntu LTS ourselves and was wondering if you have any experience getting Geoclient running on 16.04 or 14.04.

Also, will it work with OpenJDK or do I need to use Oracle Java?

Thanks!

[mlipper]

Hey @jqnatividad ,

Long-time-no-see!

Yes, I have definitely built and run Geoclient on one or both Ubuntu versions (using Vagrant/Virtual Box, Docker, or similar).

It was a while ago but basically, all the info described in https://github.com/CityOfNewYork/geoclient/blob/master/src/doc/BUILD.md applies generally to any x86_64 modern Linux distribution. Also, Issue #19 is about using OpenJDK and Issue #18 was about someone creating a Docker container for Geoclient on (I think) Ubuntu.

To summarize (from memory):

• OpenJDK 7 and 8 should work once the full JDK is installed
• Geosupport from DCP should installed (and the geo.h header tweaked using contents of geoclient/geoclient-native/etc/geo_h-fixes directory.
• Ubuntu should have gcc/g++ 4.7+ installed and the C standard and Geosupport headers/libraries on the compiler/linker's include/library paths

I realize the docs are spare , so please LMK if you want to talk it through the old fashioned way.

BTW, completely unrelated: IMHO, this latest geospatial standardization thing being discussed is on the wrong track. Your proposal in Issue #4 is a much better solution; more scalable, accurate, maintainable, de-duplicating, etc...I've stated my opinion too much already but if you're involved it's worth considering...

[jqnatividad]

Dunno if you heard, but Ontodia was acquired by OpenGov earlier this year, so been busy with integration and building product. ;)

But I'm back and getting caught up again on my home open data community - NYC!

Anyway, on geospatial standardization, I put in my 2 cents via the feedback form (https://talk.beta.nyc/t/give-feedback-on-nyc-s-proposed-geospatial-opendata-standards/2179/2), and we're actually putting together something to demo our perspective as it integrates into CKAN.

[mlipper]

Nice! Congratulations!

[chrismarx]

Hi, I'm on Ubuntu 14.04, and yes, I would really appreciate the chance to speak on the phone, I sent you an email at your github email address-

[mlipper]

https://github.com/kurtraschke/geoclient-docker/blob/master/geoclient-build.patch

./gradlew lspathGS_LIBRARY_PATH ./gradlew lspathGS_INCLUDE_PATH ./gradlew lspathLD_LIBRARY_PATH

From: chris marx [mailto:notifications@github.com] Sent: Tuesday, September 20, 2016 10:11 AM To: CityOfNewYork/geoclient geoclient@noreply.github.com Cc: Lipper, Matthew Mlipper@doitt.nyc.gov; Mention mention@noreply.github.com Subject: Re: [CityOfNewYork/geoclient] Documentation for installing GeoSupport on Linux? (#23)

Hi, I'm on Ubuntu 14.04, and yes, I would really appreciate the chance to speak on the phone, I sent you an email at your github email address-

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/CityOfNewYork/geoclient/issues/23#issuecomment-248312684, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAA2TChM978hqSSqfNLsA0FhC25x8mpgks5qr-ltgaJpZM4J0Srk.

---

This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.

[cm325]

I was able to successfully complete the build, the final problems with the math libraries in linux (ubuntu specifically) were indeed the problem, the fix you pointed to here was all I needed to do to finish the build:

https://github.com/kurtraschke/geoclient-docker/blob/master/geoclient-build.patch

It seems this is a known problem on ubuntu - http://stackoverflow.com/questions/7824439/c-math-linker-problems-on-ubuntu-11-10

Thanks for all the help so far. Now I'm looking at this section:

https://github.com/CityOfNewYork/geoclient/blob/dev/src/doc/BUILD.md#java

And I'm wondering if there are any more details about what I would be deploying locally, I'm not seeing a standard war file that I would normally deploy to tomcat?

[mlipper]

Now run

$ ./gradlew build

That should build the deployable war file. It also runs unit and integration tests, some of which use JNI. If you get an UnsatisfiedLinkError, ClassNotFoundException or similar it means that the testLibraryPath is not set correctly. By default it uses the following:

testLibraryPath=$GS_LIBRARY_PATH:build/libs:$LD_LIBRARY_PATH

The second path element is relative from the project root and gets created by the regenerate task (which actually calls the C build in geoclient-native/build.grade)

Please let me know how that goes and we'll figure out how to configure your Servlet container.

Matt

Sent from my iPhone

On Sep 21, 2016, at 9:33 PM, chris marx notifications@github.com<mailto:notifications@github.com> wrote:

I was able to successfully complete the build, the final problems with the math libraries in linux (ubuntu specifically) were indeed the problem, the fix you pointed to here was all I needed to do to finish the build:

https://github.com/kurtraschke/geoclient-docker/blob/master/geoclient-build.patch

It seems this is a known problem on ubuntu - http://stackoverflow.com/questions/7824439/c-math-linker-problems-on-ubuntu-11-10

Thanks for all the help so far. Now I'm looking at this section:

https://github.com/CityOfNewYork/geoclient/blob/dev/src/doc/BUILD.md#java

And I'm wondering if there are any more details about what I would be deploying locally, I'm not seeing a standard war file that I would normally deploy to tomcat?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/CityOfNewYork/geoclient/issues/23#issuecomment-248789957, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAA2TK1xk57ApNh_ji_Pj0Js3tZ7Vkepks5qsdrrgaJpZM4J0Srk.

---

This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.

[chrismarx]

Hi,

Ok, the build failed, the dependency for "spring-jsonp-support" was missing. I saw it's not in maven, so went to the github repo, built it and installed it locally in my local maven repo, and added mavenLocal() to the gradle.build. After I did all that, I saw the "TODO" about this in the geoclient-service/build.gradle

That solved that problem. But the build still failed after that. The error was:

Could not resolve all dependencies for configuration ':geoclient-service:compileClasspath'. Could not find jai_core.jar (javax.media:jai_core:1.1.3). Searched in the following locations: https://repo1.maven.org/maven2/javax/media/jai_core/1.1.3/jai_core-1.1.3.jar

Now, it's true, that jar is not at the above location. But it is here:

http://central.maven.org/maven2/javax/media/jai_core/1.1.3/

I added another maven repo pointing to that url to the geoclient-service/build.gradle, but it had no effect, it seems like gradle is intent on finding that jar at that location. I grepped to try and find where this is being called from, but didn't get any hits.

[mlipper]

Hi Chris,

I’ve seen this behavior also for reasons that were not clear to me at the time. I’ve had problems in the past with GeoTools and its use of its own Maven repo. I already created a ticket to get rid of the GeoTools dependency since it is only used for coordinate transformations but didn’t find anything leaner. I’ll try upgrading to the latest version or coming up with a new approach but I may not have time to close it out today**.

Regarding use of the spring-jsonp library, I think Ialready know a simple, better solution: use Spring’s built-in support for CORS in the most recent releases. I’m going to upgrade to the latest Spring versions anyway, so hopefully that won’t cause other unintended version conflicts.

Would you mind filing a couple of GitHub issues using the descriptions of each particular problem you’ve encountered? I’m most interested in missing documentation for specific tasks and straight-up bugs (like the Ubuntu link issue, missing dependencies, etc.). If you don’t have time to do this yourself, would you mind if I do it by cut and pasting some of the email content we’ve exchanged in the last few days?

Thanks,

Matt

**In the meantime you could try explicitly declaring the jai_core dependency and excluding it from the GeoTools dependency. You mentioned that you’re not familiar with Gradle so no worries if this seems like too much to bite off at once.

From: chris marx [mailto:notifications@github.com] Sent: Thursday, September 22, 2016 10:49 PM To: CityOfNewYork/geoclient geoclient@noreply.github.com Cc: Lipper, Matthew Mlipper@doitt.nyc.gov; Mention mention@noreply.github.com Subject: Re: [CityOfNewYork/geoclient] Documentation for installing GeoSupport on Linux? (#23)

Hi,

Ok, the build failed, the dependency for "spring-jsonp-support" was missing. I saw it's not in maven, so went to the github repo, built it and installed it locally in my local maven repo, and added mavenLocal() to the gradle.build. After I did all that, I saw the "TODO" about this in the geoclient-service/build.gradle

That solved that problem. But the build still failed after that. The error was:

Could not resolve all dependencies for configuration ':geoclient-service:compileClasspath'. Could not find jai_core.jar (javax.media:jai_core:1.1.3). Searched in the following locations: https://repo1.maven.org/maven2/javax/media/jai_core/1.1.3/jai_core-1.1.3.jar

Now, it's true, that jar is not at the above location. But it is here:

http://central.maven.org/maven2/javax/media/jai_core/1.1.3/

I added another maven repo pointing to that url to the geoclient-service/build.gradle, but it had no effect, it seems like gradle is intent on finding that jar at that location. I grepped to try and find where this is being called from, but didn't get any hits.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/CityOfNewYork/geoclient/issues/23#issuecomment-249088773, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAA2TJqjMO4VLHcU31W2tEP2hqwmd2W1ks5qsz4ogaJpZM4J0Srk.

---

This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.

[chrismarx]

Sure, I can create some tickets. I was going to suggest the same thing for jsonp issue, Spring 4 added really nice jsonp with controller advices, and cors support as well. Spring boot really cuts down on the configuration too.

As for the jai issue, yes I will gave that a try, I'm picking up gradle fairly quickly. In general, I just don't know how much time to invest on my own figuring out problems if they're already known, so I usually opt to post about it, unless it looks straightforward, like the jsonp problem-

[chrismarx]

**In the meantime you could try explicitly declaring the jai_core dependency and excluding it from the GeoTools dependency.

Ok, I gave this a go. The build does complete now. First I tried this:

1. exclude jai_core from the two geotools dependencies: compile("org.geotools:gt-main:$geotoolsVersion") { exclude(module: "xerces") exclude(module: "jai_core") } compile("org.geotools:gt-epsg-wkt:$geotoolsVersion") { exclude(module: "jai_core") }
2. Manually include the jai_core dependency:

compile("javax.media:jai_core:1.1.3")

That didn't fix anything. Then I also installed the dependency locally:

mvn install:install-file -Dfile=./jai_core-1.1.3.jar -DpomFile=./jai_core-1.1.3.pom

And that eventually did the trick. Seemed like I had to clear gradles cache for that work. Interestingly, I thought maybe the jai_core dependency was being pulled as a transitive dependency from another source. A couple of websites mentioned the following method to show a complete transitive dependency tree from gradle:

http://stackoverflow.com/a/29671233/228369

So I did that. But the output lacks any reference at all to jai* anything.

It might be worth pointing out that the war file is generated in the :

~/git/geoclient/geoclient-service/build/libs

folder. Not being familiar with gradle, my first thought was that the war file never got generated, but grepping around did the trick :)

I installed jetty, and deployed the war. On startup I get this, which you mentioned I might see duing the tests, but the tests succeeded (or would they not fail upon getting kind of error?):

Error creating bean with name 'geoclient' defined in class path resource [gov/nyc/doitt/gis/geoclient/service/configuration/AppConfig.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [gov.nyc.doitt.gis.geoclient.jni.GeoclientImpl]: Factory method 'geoclient' threw exception; nested exception is java.lang.UnsatisfiedLinkError: no geoclient_jni in java.library.path

[mlipper]

The is issue is that the JVM used to run Jetty cannot find the shared object files for Geosupport and Geoclient. To fix this I recommend the following (container-agnostic) steps:

1. Add Geosupport and Geoclient's shared librarys to the LD_LIBRARY_PATH environment variable for the environment in which the JVM will run:

   # Assumes you've built and copied the geoclient libs to /opt/geoclient/lib
   $ export GC_LIBRARY_PATH=/opt/geoclient/lib
   
   # Assumes base geosupport installation in /opt/geosupport
   $ export GS_LIBRARY_PATH=/opt/geosupport/lib
   
   # Geosupport needs this set. Remember the trailing slash!
   $ export GEOFILES=/opt/geosupport/fls/

   Note that the actual path(s) used are arbitrary. As long as GEOFILES is set properly and the directories containing all shared libraries for both applications are specified.

2. On the command line or in a shell script used to start the container, add the following to the existing arguments to the java cmd line which starts your container:

   $ java -Djava.library.path="$GS_LIBRARY_PATH:$GC_LIBRARY_PATH" ...etc..

3. (Might not be necessary) If the geoclient Servlet context still fails at startup with a similar Exception, then try the following hack before invoking the command line in 2.

   # Standard environment for runtime library path on Linux 
   $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GS_LIBRARY_PATH:$GC_LIBRARY_PATH

NOTE: Based from the Tomcat site and other sources, my understanding is that Servlet-based apps calling native code (i.e., System.loadLibrary(...)) should place the jar/class files into Tomcat's shared Classloader (shared by the container and all its Serlvet contexts) to avoid class loading issues across restarts.

This means that if you deploy the Geoclient war file into the same Tomcat container (defined in conf/server.xml) with other Servlet contexts that also use Geoclient, then the geoclient-jni-2.x.x.jar and the gluegen-2.x.x.jar jars should be placed in $CATALINA_HOME/lib. (I think the current Gradle build supports building both with/without these jars in the WAR file).

I'm not sure whether this applies to Jetty but unless absolutely necessary, I suggest using virtual hosts and deploying WARs which use the geoclient JNI jar files in-process (through import gov.nyc.doitt.gis...) to their own separate containers. This is also helpful for maintenance, monitoring, debugging, scalability, etc. so generally, IMHO, a good practice anyway.

When running Tomcat, I've found the easiest way to set-up the environment as shown above is by adding/updating either the $CATAINA_HOME/bin/setenv.sh file. I'm sure Jetty (version 9 definitely) has a similar configuration option.

Let me know how it goes,

Matt

[chriswhong]

Hi all, I was tinkering with installing GeoSupport on Ubuntu (16.04 in a docker container) and had success calling the geo() function with a hard-coded string. I wrote it up here for anyone who might find it helpful.

My intent is to write node.js bindings for geosupport.

https://gist.github.com/chriswhong/2e5f0f41fc5d366ec902613251445b30

[mlipper]

Hey Chris,

Thanks for sharing this information. As an FYI:

Geoclient already provides an in-process Java API that you can use locally instead of the REST interface. Like the rest of the Geoclient source, it is not well documented yet, but running on 64-bit Linux, using Java 7 or 8, it provides near or equal performance to native C. Our intention is to eventually provide basic bindings for languages which have basic C integration (Python, Ruby, etc.) and Node certainly falls into that category.

JVM languages (Groovy, Jython, JRuby, Clojure, etc..) can already use the various Geoclient API's including the core Function/WorkArea/Field abstractions. I know there's JVM-based Node implementations that might "just work" as well but I don't have any direct experience with them.

Please let me know how it goes with your project and if you're interested in providing feedback for or contributing to Geoclient in some way.

Thanks, Matt

[chriswhong]

Will do. I have about as much experience with java as I do with C (read: none). What are the benefits of using node > java > geosupport instead of just node > geosupport? The obvious is that you have already written the java api, that abstracts the direct communication with geosupport, but to use it I would need to have a more complex environment with both java and node, and the dependency issues that both involve, right? Any pitfalls there?

[mlipper]

You've mentioned the primary benefit: Geoclient already exists and has worked well both in-process and remotely. I'm not sure there is a benefit here but the JRuby, Clojure, etc. communities report platform independence, real threads (w/out GIL) and performance as a few benefits running on the JVM.

In this case, I think it depends upon how you're trying to use Geosupport. Are you looking for an easily scripted way to geocode large files on a single machine or are you looking to build an industrial strength distributed batch processor capable 100's of transactions per second (like the one Geosupport provides on the mainframe)? I guess the flip-side of your question is whether your app has to be written in Node if it is intended for this type of use in-process?

Another thing to consider is running Geoclient/Tomcat on localhost and accessing it via loopback. This performs well but I agree direct integration is ultimately better.

[chriswhong]

I think the most likely use case is ETL, such as in this example:

https://github.com/NYCPlanning/dob-permits-geocode

We geocode the DOB permits data nightly, and output a shapefile. To avoid all the network traffic of sending every row to geoclient, we have a postgreSQL database and are grabbing geometries from matched BBLs and Bins in PLUTO and Building footprints datasets. I think we can just lookup BBLs and Bins from geosupport, so a simple node API for these would let us do the whole workflow without any network traffic and without a database.

The other use case is on-the fly inclusion into the node-js (express) backend we are building for a few apps here at DCP.

On Sun, Oct 2, 2016 at 1:36 PM, Matthew Lipper notifications@github.com wrote:

You've mentioned the primary benefit: Geoclient already exists and has worked well both in-process and remotely. I'm not sure there is a benefit here but the JRuby, Clojure, etc. communities report platform independence, real threads (w/out GIL) and performance as a few benefits running on the JVM.

In this case, I think it depends upon how you're trying to use Geosupport. Are you looking for an easily scripted way to geocode large files on a single machine or are you looking to build an industrial strength distributed batch processor capable 100's of transactions per second (like the one Geosupport provides on the mainframe)? I guess the flip-side of your question is whether your app has to be written in Node if it is intended for this type of use in-process?

Another thing to consider is running Geoclient/Tomcat on localhost and accessing it via loopback. This performs well but I agree direct integration is ultimately better.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CityOfNewYork/geoclient/issues/23#issuecomment-250983713, or mute the thread https://github.com/notifications/unsubscribe-auth/ABv7XOTl2Jtocco8eJRfqtqVPJt_OXKvks5qv-uMgaJpZM4J0Srk .

[mlipper]

If you're looking up attribute information based on known identifiers (BIN, BBL) that's already available from a relational database then I'm not sure why you would use Geosupport in the first place; the NYC-domain/context-specific search is awesome but otherwise it's just another type of data source minus: the ability to do actual spatial queries, the support for a well-supported and easy to use query language (SQL, OGC spatial, etc..) and the prepackaged installation. (I'm being dork and exaggerating but my point is that Geosupport scratches a different kind of itch than an RDBMS).

In my personal experience, integration with ETL's using asynchronous file streams are often the easiest to maintain and re-use from multiple runtimes regardless of the language in which they're written. Geoclient has been used this and in other in-process ways for a while now. Also there's a big difference between a call to a truly remote host and one that uses the loopback to use HTTP for inter-process communication (yes, I know that this is a bad idea if speed and throughput are your primary concerns).

Regardless, I clearly know nothing about your goals/needs for stuff you're working on so I'm just flapping my lips. I like the idea of having dead-simple, low-level bindings for Geosupport for easy integration with popular runtimes so if there's specific things you think would make it more usable for your needs please let me know. Suggestions, contributions, discussions, etc. are always welcome too.