Skip to content
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

Geotemporal geocoding #4

Open
jqnatividad opened this issue Jan 13, 2016 · 7 comments
Open

Geotemporal geocoding #4

jqnatividad opened this issue Jan 13, 2016 · 7 comments

Comments

@jqnatividad
Copy link
Contributor

Ability to specify date when geocoding. This will allow users to see how an addresses' attributes change over time (e.g. congressional district, election district, etc.)

This will require using older releases of Geosupport based on the given date.
cc @rcheetham

@mlipper
Copy link
Member

mlipper commented Jan 13, 2016

I love this idea and hope to be able to do something like this one day. For the moment, however, there a couple of practical, operational and technical issues that prevent it from being added to a planned release:

  • Each full Geosupport distribution takes ~2G of disk space. There are a minimum of 4 Geosupport releases per year, but usually there are more. The current publicly hosted installations on the NYC Developer Portal already have disk capacity issues such that we've had remove older releases from the file system to make space for new ones. Obviously, in today's world, 2G is almost nothing. However, the money currently budgeted for this project is also almost nothing. So, in other words: $
  • We are working with DCP to operationalize delivery of new and access to old binaries. Thus far, their developers (Steve O.!) have been very cool about getting us what we need when we ask for it. To implement a feature like this, however, we'd need to automate things and provision resources for file storage, transfers, download, etc. Good news is that we're already discussing it. Bad news is even if all parties are on board, we have to go through the same exercise with our respective agencies and that just takes time.
  • I don't consider this to be a show stopper, but it is a technical issue which can't be ignored. Binary compatibility and application compatibility are generally stable with each release; however, they do change. Implementing this feature would require that Geoclient maintain a matching metadata and build configuration for each new Geosupport release. The metadata aspect of it is not such a big deal because the code is essentially just a big data munger that uses metadata descriptions to pull out the proper data elements from a large character array. The binary aspect, however, could be a problem if changes to Geosupport required recompiling/re-linking. I know there are ways to deal with this (dlopen, run geoclient as multiprocess app using xyz protocol to implement interprocess communication, etc.) but I don't have enough experience writing C/C++ apps that do this type of thing to have a real sense of the level of effort.

So...from my perspective, this is definitely a "nice to have". In the short term, I think it's more important to focus on making the current feature set easier to build, install and run across different platforms. Just my 2 cents of course...what do you think?

@jqnatividad
Copy link
Contributor Author

Awesome! Having this capability would really be a great differentiator for Geoclient that will support some real-world use cases in urban planning, research and real estate.

I guess once v2 comes out and there's more clarity on how to do an on-prem Geoclient/Geosupport combo, I hope incented members of the community can contribute to the development effort to stand up this feature.

@mlipper
Copy link
Member

mlipper commented Jan 14, 2016

We're working on more detailed instructions for building and installing now. To be clear, I can't say if/when we'd implement this feature because of all the reasons mentioned above.

@jqnatividad
Copy link
Contributor Author

Crystal clear! Now that Geoclient is open-source, I'm sure it won't be long when users start "scratching their itches", and in their enlightened self-interest (e.g. some real-estate company, a researcher who gets a grant, a govtech supplier to the City, etc.), start contributing back.

@mlipper mlipper added this to the definitely-maybe milestone Jan 15, 2016
@mlipper
Copy link
Member

mlipper commented Jan 15, 2016

Joel,

I'm adding this to the "wish list" which I've created to capture enhancements that are not scheduled but could be in the future, weather permitting.

If you decide to implement this yourself: LMK if you have technical questions you think I can answer and I'll do my best. Would be cool and in the simple case of not trying to support versions which are not binary-compatible, very little actual coding involved that I can think of.

Thanks!
Matt

@mlipper mlipper closed this as completed Jan 15, 2016
@mlipper
Copy link
Member

mlipper commented Jan 15, 2016

DOH! wrong button :-p

@mlipper mlipper reopened this Jan 15, 2016
@jqnatividad
Copy link
Contributor Author

Awesome! Having it as a "wish list" item on the main repo guarantees a lot more eyeballs will see it! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants