We are the music makers and we are the dreamers of dreams


Published on

Brent Porter, GIS Programmer, Texas Commission on Environmental Quality

Presented at the 2011 Texas GIS Forum

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

We are the music makers and we are the dreamers of dreams

  1. 1. We are the music makers andwe are the dreamers of dreams. Brent Porter, TCEQ
  2. 2. Who am I?  Programmer and GIS Administrator for ArcGIS Server and ArcSDE, TCEQ  Austin Community College Adjunct Professor  Emergency Responder  Examples  - Hurricanes  - Deepwater Horizon Oil Spill
  3. 3. A little bit more about me  Yes, I am an ESRI fanboy and unrepentant at that!  …but I am also a pragmatist and I care A LOT more for solutions that work best in a sustainable way with the least effort possible.  What? Yes I want to have my cake and eat it too
  4. 4. Why That Title?  Poem by Arthur OShaughnessy  Link – the phrase in the context of my day to day work…  This exemplifies my development philosophy  Dream Big!  Interesting  Fun for me
  5. 5. Why continued…  Also, there is always someone wanting to tell me that there are NO snozzberries!  As the experts in our field, it is our job to teach those snozzberry doubters about what we are doing and why  And who doesn’t want to make music and dream big dreams?!?!
  6. 6. Today’s topic  Talk about how and why I made the dev choices I made with a new experimental template.  Hopefully you’ll be inspired by what I am innovating with the UI and some of the other functionality.  Deny the naysayers the satisfaction of being right!
  7. 7. Why Javascript?  By Steve Paine
  8. 8. Javascript  They are starting them young now!  Really though  Mobile Development – lots of great mobile javascript library support out there  HTML 5 – browser vendors are actually in agreement. All are working towards a set of standards because of the mobile revolution.  Works with Smartphones, Desktops, Laptops, Tablets – all from a common codebase!
  9. 9. What Javascript?  Javascript API for ArcGIS Server/Dojo  JQuery/JQuery UI & some plugins  Google Maps API Geocoding Services  Google Maps API Street View  NodeJS  Custom Javascript
  10. 10. JQuery/JQuery UI  JQuery is one of the big open source javascript libraries out that is getting used by lots of big companies to do great user interactions  Easy learning curve for basic functions and well documented
  11. 11. JQuery/JQuery UI  JQuery UI adds widgets and other skinning effects  Easy to choose one of the many themes for the look and feel of your app  Or you can create your own with the ThemeRoller!
  12. 12. Google Maps API Geocoder  Wait a second…ESRI Fanboy, confusion what’s going on?  I’ve spent too much time wrestling with the ESRI geocoding service  I’ve even given talk here at the Conf in ’08 on it  ESRI works great for basic ‘vanilla’ geocoding (simple addresses, cities)  Other than this…. not so much!
  13. 13. Contrast this with Google’sGeocoder  Very forgiving of user input…  Great for place name searches for points of interest and intersections  Research into this topic has yielding some interesting facts  They use a spatial filter to prioritize the return results  Multiple methods for searching for some of the values (AND, @, | (pipe)
  14. 14. More on locators  Experiments on ESRI geocoder  Lowering the Candidate Score Filter (defaults to 80 in Javascript API)  Removing the filter, adding a spatial filter and then doing the score filter  Adding in additional Place Name/Points of Interest queries beyond the default through pattern detection
  15. 15. Even MORE on geocoders  Obviously there are ways of doing more sophisticated things with the esri geocoding – but lots of them have to do with having add on datasets or features and additional configurations but I ask you, Why?  The google maps api geocoder just works…given a little bit of configuration AND it is easy to integrate with arcgis server
  16. 16. Google Maps API Street Viewservice  Some groups of users really like Street View  Provides the ‘on the ground’ photo that is necessary for some types of applications. It really ties the map application to any physical extension or coordination being done  Works great in conjunction with the Google Maps Geocoder
  17. 17. Node.js  Node.js – server side javascript. In effect, javascript that runs through a run time compiler on the server and only emits results to any clients accessing it.  Based on the concept of event driven programming  Yeah… but WHY?
  18. 18. Why?  Is Node.js that fabled silver bullet of programming?  No  But it can be very useful for a certain problem space in application development  According to a mashable.com article back in March of this year – [Node.js] is great for event-driven low latency, concurrent apps  So… things like a massive online scrabble application!  Or, a chat server for clients
  19. 19. Facilitating Collaboration ingeospatial applications  There is a real need for a certain kind of application to enable real-time collaboration in conjunction with a map  Emergency Response  Law Enforcement  Outreach with particular users  Recognizing the need I set out to develop a solution we could use with Javascript
  20. 20. The solution  Node.js has a simple chat app/client you can make with only a minimal effort  Link to the chat server through an iframe in your javascript app and you have what we see in the demo
  21. 21. And on that note…  What if users wanted the ability to share a common operation picture?  They already want this and there are umpteen thousand viewers that can be used for THAT!  What about being able to share a common map view/extent and layer list in near real time (with a 3-5 second delay)?!?!
  22. 22. Geocollaboration Manager  We are experimenting with building a custom app that allows a single user(pc) at a time, to act as Cartographic facilitator. AND some number of clients that would see the results from the cartographic facilitator.  Let’s look at a diagram of the architecture
  23. 23. Flow
  24. 24. Geocollaboration Session Data MAPVIEW_ID MAPVIEW_URL BASEMAP_ID MAPSCALE MAPPRJ FK_SESSION_ID FK_GROUP_ID STATUS MAPWIDTH MAPHEIGHT LAYERS_ACTIVE 347 url to rest service 23 24000 4269 1 1 Inactive 400 300 1,2,6,7 348 url to rest service 4 24000 4269 1 1 Active 800 600 2,3,4,5,8
  25. 25. Take aways  This functionality provides a level of ‘commonality’ for purposes of collaborating without doing desktop sharing sessions that isn’t out there yet.  It is also possible to extend this so that we take those parameters stored for any particular session and create a record of the time spent in collaboration – the images are stored with the session or the url to the session. A ‘map book’ could be created and sent to the attendees.  Future research – trying to use some of the advantages of Node.js as a potential avenue for reducing the computational cost of the collaboration manager component.
  26. 26. So…  Remember that the technology option you choose is a consideration for successful application development  But, as technology matures and APIs and languages get better about working across differences, it isn’t the biggest consideration.  Most important to be successful is to have the right attitude…
  27. 27.  keep asking questions! Dream big Make music Take chances Fight the snozzberry haters
  28. 28. Questions?  My email at TCEQ  bporter@tceq.texas.gov