mlipper
commented
8 years ago 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
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