Hello from geoclient

[mlipper]

Hello from geoclient

[mlipper]

Hi Jeremy and Ian,

Happy New Year! Thank you both for your responses.

Time permitting, I'll try to flesh out a basic prototype capable of serving implementation-neutral Geosupport client config serialized as JSON over HTTP(S). I'll aim for a superset of the info provided in python-geosupport's function_info module and geoclient's geoclient.xml.

I'll let you know if/when there's enough functioning source to warrant a GitHub repo.

Thanks!
Matt

[ishiland]

Hi, i'm definitely willing to assist in some capacity. I am not very familiar with geoclient but I would be interested in hearing your thoughts on how to implement a binding to it. If we are able to use the basic design pattern that's already been established with python-geosupport, it may be transferable to other languages. Please let me know how I can help or how you would like to facilitate this effort. Regardless, thanks for reaching out.

[mlipper]

I'm sorry for not following up sooner -- last week, things at work got crazy.

I'm thinking about a few areas where some discussion or collaboration would benefit both of our projects and/or the Open Source NYC developer community at large:

• "Standard" (or at least conceptually similar) configuration meta-data format for externalized Geosupport work area configuration. I'm not talking so much about the file format/encoding itself (e.g., CSV that you're using or XML that I'm using); I'm thinking about any machine-readable data structure(s) that define (among other things):
  • Positional attribute indices
  • Unique identifiers for functions, work areas, attributes
  • Conventions for indicating "compound" attributes (e.g., BIN, BBL, etc.), attribute and function aliases, white space formatting, string pre/post processing, attribute defaults, etc.
• Given some degree of common interest in the above: writing a mini configuration/continuous delivery server accessible via a REST API capable of allowing multi-node clusters of server processes (e.g., geoclient-service) to participate in non-invasive, DCP data enhancements, updates, etc.
• Shared documentation project and/or collaboration via generated site/reference guide (Asciidoc, Jekyl, Read the Docs, etc.) for language-neutral info: setup tasks, troubleshooting, etc.

To me, the ultimate goal would be to do any or all of the above collaboratively with the appropriate DCP teams. I've discussed some of these ideas with various DCP staff members over the years and I've certainly relied on their patience and kindness in helping me understand how Geosupport works. However, it's been a long time since I've pursued a detailed technical discussion with DCP that would allow for further automation and maintenance of the various Geosupport client apps and APIs that exist.

No worries if none of these ideas make sense for python-geosupport right now.

Thanks,
Matt

[docmarionum1]

Hi Matt!

I think it's a great idea to try and create a standard machine-readable format documenting the input, output and functionality of geosupport.

I created the current CSV format that python-geosupport is using. It was mostly manually compiled from the user documentation and from Ian's previous work. At the time, I was just going with something that worked for me, and was general enough that I didn't have to code each function. But in no way do I think that it would be right as a more general representation.

At the time I worked on python-geosupport, I hadn't much experience with geosupport in general, and put the work in on python-geosupport so that I could use it in my existing python work. But once I got it working, I quickly realized the limitations and have since largely moved away from using geosupport. I'm still using geosupport (via python-geosupport) for street name normalization, but for the other functions I was interested in (street stretch, address and intersection) I've moved away from it.

Since I'm mostly moving away from using geosupport, I'd selfishly like to see the metadata standardized so that I don't have to maintain python-geosupport as much it going forward. It would be great if it could hit a central place that is updated as geosupport changes.

That said, I'd be happy to help get the ball rolling on this.

• Jeremy

[ishiland]

Hi Matt and Jeremy,

A standard config file would be a great addition. Writing a config file (a rudimentary JSON first go-around) was tedious so I have no doubt it will be helpful for the maintenance of this project and development of any future projects.

I'll have to get a better understanding of how the mini configuration/continuous delivery server would work and the full scope of its intention but it seems like an interesting idea. I also agree that shared documentation would be very helpful.

I am mostly doing javascript web development these days, with some use of python-geosupport for ETL processes but I will gladly contribute to any or all of these efforts when I can.

Consider me ready to assist.

Thanks,
Ian