Skip to end of metadata
Go to start of metadata

//========= CDI TSWG MAD Meeting =============//

24Jan2012

Attendees

Tim Kern (Lead, Presenter)

Brylian Foronda

Burl Goree

Cian Dawson

Dave Govoni

David Maltby

Derek Masaki

Greg Gunther

Jennifer Carlino

John Aguinaldo

Megan Hines (Presenter)

Mini Methew

Scott McEwen

Travis Lawall


 

@USGSted Project


 

Tim Kern (ppt) talked about USGSted Project (conceptualized by Paul Earle, National Earthquake Information Center), using Twitter as a means to support science.  ted = Twitter Earthquake Dispatch Project.


  • The software was developed by Jeff Allen (Java Developer) with Laura Smyrl (Project Mgr) at the Fort Collins Science Center.


  • Deployed at NEIC by Michele Guy


  • Server-based Web app running on Linux & Tomcat, consumes and provides tweets


  • Consumer component


  • Looks for "earthquake" and synonym hashtags


  • Harvests tweet metadata, including location info as available


  • Geocodes textual location info


  • Allows blacklisting (to weed out "noise") and data recapture


  • Provider component pushes NEIC info from @USGSted account


  • Mgmt utils allow development of keyword list, etc.


  • Tweeter does a tweet.  Twitter broadcasts tweet. Yahoo PlaceFinder Lookups are used to parse location text string.  Most twitter accts don't provide a location point; they provide a location string, instead.  But location info is increasing.


  • Userid is helpful for filtering out "marketing" noise from marketeers.


  • Source code will be available tomorrow at source.sciencebase.gov or on github


 

Proposed CDI Twitter Project:  Citizen Science Observation Platform - Using Curated Twitter and GeoRSS Enabled Feeds


 

Derek Masaki and Megan Hines ...


 

from Cian Dawson:  You can't DM an account on twitter unless they are already following you & have their account set to accept DMs.

from Cian Dawson:  Might want to talk to NOAA about their project http://www.nws.noaa.gov/stormreports/


 

O'Reily has printed a useful pub called ...


 

Open Discussion


 

"Augmented Reality" (Derek Masaki) will be the topic in 2 weeks, Feb 7.

"Fish Passage Barriers" (David Maltby) will be the second topic.


 

On Feb 21, ... (NY)


 

New York City Cricket Crawl & Hawaii Croci Frogs - Citizen Science events (Derek Masaki)


 

//========= CDI TSWG MAD Meeting =============//

29Nov2011

Attendees

Scott McEwen

Dave Govoni

Steve Tessler

Elizabeth Sellers

Nina Chenkeli

Julie Recker

Sarah Courchesne

Jeremy Newson

Tim Kern


 

Invasive Species Partnership


 

iMapInvasives -- tool to engage citizen scientist and for resource manager. iMapInvasives started as a desktop site, tried to leverage open source software. Backend - PostGre + PostGIS. OpenLayers front-end + hmtml5 and CSS.


 

Soon after launch of online site, a lot of citizen engagement that requested app for smartphones. This resulted in brainstorming about apps -- investigated native vs. browserbased apps. Intention is pretty simple, so keeping it to collect observation data and observation data.


 

iMapInvasives is devised to replace Nature Conservancy's weed information system. So there is intention to build a more robust tool. One of the issues that is pushing towards at a out of the box solution, is that a lot of NY  state doesn't have good network connections. So browserbased apps may not be a the best solution. Hoping push for html5 and more browserbased apps would push it to that direction as HTML5 matures along w/ universal broadband coverage.


 

Determine the best way to engage citizen scientists for NY state. NY has prisms --


 

prism - partnerships for regional invasives management


 

prism is the link to NYNHP's link to citizen scientists and other projects involving invasive species.


 

iMapInvasives: this is a tool to view invasive species data -- online training on youtube. if you're not a imap user, you can still view 10 most common invasive species across the NY state. Allow to look up species by state, county,


 

screenshots of iMapInvasives dashboard -- functionality overview.


 

iMap developed over time and initially displayed point data adn later used clustering techniques.


 

Observation Desktop data entry: who/ what/ when/ where


 

Mobile App:

- What would be the best way to do a mobile app for this? Researc shows UCLA has an app framework (What's Invasive) that could be leveraged. Issue is it doesn't allow as many species as NYNHP has (300). Can be used locally for collecting common invasive species (maybe 10 or 20). Focus on common invasive species b/c it helps w/ early detection. This will send email alert to people who are concerned. Also most citizen scientists are most useful w/ detecting common species.


 

Since then the app has been used w/ a changed CSS stylesheet.


 

Another app -- an app called iGIS. It has a lot of advanced features -- can use Shape files, and can work w/ ESRI products. Can be customized w/ custom base map.


 

Currently focused on browser based mobile app -- allows the best amount of coverage (no full time developer to focus on different platforms) and also easier to maintain code base. Currently working w. iOS and Android, but would like to include BB as well.


 
 

Browser Based vs Native App


 

Browser:

Largest pro is single set of code base (just tweak css), cross platform, data directly uploaded to cloud, access to content.


 

Con: Neet to be connected (need to make it a cacheable app -- this is still in progress ), hardware limitation (cannot invoke a camera programmatecially), less "App-ish" (advances being made in making it more app looking)


 

Native App:

Pros: familiar look and feel. Disconnected use. Access to device species hardware/OS API.

Cons: Device specific develpoment (ROI high), updates much more time consuping, dealing w/ TOS/APP store


 
 

Boyond Citizen Science: tring to get an advanced data entry app for


 

Assessment: polygon showing localized distribution, disturbance, maturity and densitiy of a local invasive.


 

Treatment: steps taken to remove or control invasive barrier, bio-agent, chemical (herbicide, pesticide), fire, grazing, mechanical, shooting, trapping


 

Survey: Intentional and systematic searh for a specific invasive surpvey type


 

Occurrence: group of geographically similar observations of a single species. -- this means a species can be submitted by multiple cit scientist.


 

Scientists & Land Managers -- Browser based vs. out-of the box app:


 

Brwoser:


 

ros: single set of code, cross platform, direct to cloud, access to content online, free

Cons: neeed to be connected, hardware limits, less app-ish


 

Out of the box:


 

Pros: functionality already built, customizable, disconnected or


 
 

Out of the box solutions:

Open datakit (ODK) --> sponsored by google

Episurveyor

Cyber Tracker

Phone Gap --> allows to create a wrapper around a browser based app and make it native


 

Free Software:

ArcPAD (windows mobile)

ArcGIS Mobile (iOS, Droid, Windows)

Trimble Terrasync (windows mobile)

Pendraggon forms (multiple)

iGIS (iOS)


 

Mobile apps are currently lagging behind the desktop site, but in the future that will most likely become the primary method of data collection.


 

Q&A:


 

Issue w/ PhoneGAp -- was bought by Adobe.

Tim Kern's group is concerned. So using both Phone GAp and Titanium. Haven't tried deploying PhoneGap through App Store.


 

Developer for iMapInvasives is a big Open Source fan and is using a lot of interesting

HTML to Python -- Jango


 

Can all the functionality be implemented using HTML5?

Most functionality required can be implemented using HTML5, but currently biggest limitation w/ web browser based app is not being able to submit a phone directly.


 
 
 
 
 
 
 

//========= CDI TSWG MAD Meeting =============//

15Nov2011

Attendees

John Aguinaldo

Scott McEwen

Megan Hines

Tim Kern

David Maltby

Travis Lawall

Julie Recker


 

Global  Feducials website


 

Geared for desktop but also building in features for mobile


 

YUI3 was used -- one of the only major library that does not distinguish between mobile and desktop -- this was picked so that apps developed for desktop using this library could be ported w/o work to tablet. Drag components also need to work.


 

Another strategy is to detect how much screen space is available.


 

Demo of GFP website - currently not even in Beta. Working to get minimal functionaliry in it.


 

Entrance by searching on keywords (can search by regions).

Goal of this website is to allow users to explore the imagary w/o having to download the images.


 

Have tools built in to do location based searches.


 

Initially no testing for mobile compatibility but no major issues as the libraries originally picked is mobile compatible.


 

ipad demo -- everythjing works except for the hover event


 

Mobile coding issues:


 

Dynamicallly size page elements


 

Custom build libraries for minimal load -- YUI3 is already modular. You don't need to load the entire library


 

Leverage accelerometer for map navigation


 

OpenLayers -- a lot of the mobile featuers is already built in. But there are specific contls that you can override.


 

YUI3 -- graded browser support. Attempt to be compatible with 99% of the browsers unlike jQuery or Sencha Touch.


 

YUI3 is more of a web framework with MVC built-in. Makes it much more easier to do large projects. Has no issues w/ cross-browser compatibilty.


 

YUI using GitHub


 

leaflet.js -- new mapping library


 

internal usgs code repository


 

cloudMade


 

SVG is the way to go -- styling lines on the fly. On the user end customizing their own apps.


 

ArcGIS  canvas libraries --


 

//========= CDI TSWG MAD Meeting =============//

02Aug2011

Attendees

Dave Govoni

Shiji Thomas


 

USGS Mobile Applications Development Support Framework "Pre-Proposal" -- scroll down to bottom of:  https://my.usgs.gov/confluence/display/cdi/CDI+FY12+Proposal+Ideas


 

AE (Enterprise Web) GMU student with some experience and interest: Christopher G Hill <chill@usgs.gov>


 

//========= CDI TSWG MAD Meeting =============//

19Jul2011 : Appcelerator - Lessons Learned

Attendees

Farial Shahnaz (Lead)

Abby Benson

Brad Williams

David Maltby

Julie Recker

Scott McEwen

Shiji Thomas

Travis Lawall


 

Presentation:  Appcelerator - Lessons Learned by Travis Lawall


 

Appcelerator, ($2,400/year; may be less now) a JavaScript toolkit, supports multiple mobile platforms and greatly decreases developer's time, but the developer must still deal with exceptions with each platform.  Therefore, code is focused on iPhone.  However, still helps keep code consistent across platforms. Appcelerator fills a gap until HTML 5 is fully implemented/deployed.


 

Demo of "Species Spotter" for citizen scientists to input tree species, river bank, and photo; app automatically geotags location.


 

Making it easy on the user to access

Interface design challenge: what controls to pick

Do a lot of Beta testing

Taking into account network connection -- when to cache


 

Demo of "I felt it" to display world-wide earthquakes from last 24 hours and last 7 days.  iPhone user can view quake locations and data, as well as add experiential info about a given quake.


 

Used RSS feeds:  last 27 hours and last 7 days.

Device orientation affects design decision

Native picker was slow; wrote own.

Uses table views to manage layout; easier to resize when adding rows and columns.


 

Demo of "KitchenSink"?

Created Android app w/ PhoneGap, but Appcelerator seems to have more capabilities.


 

Please email rviger@usgs.gov if you are not able to access http://usgs.titanpad.com/cdi-tswg-mad .  


 
 
 

//========= CDI TSWG MAD Meeting =============//

05Jul2011 : Overview of HTML5


 

Please email rviger@usgs.gov if you are not able to access http://usgs.titanpad.com/cdi-tswg-mad .  


 

Attendees

Alan Vaughn - new member

Gary Fisher

Shiji Thomas

Julie Recker

Burl Goree

Megan Hines

Don Holmes

Dave Govoni

David Boldt

Mark Hamil

Tim Mancuso

Brad Williams

John Baer

David Maltby


 

----


 
 

//========= CDI TSWG MAD Meeting =============//

21Jun2011


 

Please email rviger@usgs.gov if you are not able to access http://usgs.titanpad.com/cdi-tswg-mad .  


 

Attendees

Jeremy Newson

Mark Hamil

Abby Benson

Scott McEwen

Farial Shahnaz

Megan Hines

Dave Govoni

Mark Kutsko

Travis Lawall

David Maltby


 

- Should we focus on a specific platform at first or should we do a broad overview? May need ot poll the group to determine interest.

Development


 

- Looking forward we need volunteers to discuss different topics such as best practices, mobile web vs. native app, etc. Unfortunately, we don't have anyone on the call that has done development.


 

- Mark Hamil -- high level overview


 

- Don't have access to the camera and file system in many of the phones so development depends on what you want to do.


 

Maybe there needs to be a matrix of the different technologies out there and the pros and cons of each?? e.g. HTML5/PhoneGap/RhoMobile/Adobe Air


 
 

Sessions:


 

July 5: HTML5 overiew -- David Maltby / mobile web app: David Maltby -- HTML5 app for mobile web -- adobe web premium 5.5 - flex -- helps determine fish passages (this is not HTML5 it is Flash). David Maltby


 
 

I have an HTML5 app that shows AHPS sites that you can click and get the current gage height.


 

Basic info: What do you need to get started? What tools need to be in place? -- Start with mobile web.


 

July 19:

Travis Lawall -- appcelerator/phoneGap -- javascript engine wrapper -- developed for both Android and iOS. Technical details:

Appcelerator (?) on iphone thinking about using phonegap.  Good give a demo factoring based on the UI.)

+ lessons learned + best practices.


 
 

Aug 2:

UI questions: Megan Hines, Dave Govoni,


 

Epicollect -- perhaps get the developer to present - Megan H.

+ other Data collection apps -- make or buy scenarios.


 

Sept

Maybe there needs to be a  matrix of the different technologies out there and the pros and cons of  each?? e.g. HTML5/PhoneGap/RhoMobile/Adobe Air


 
 
 
 

Brad Williams - Android


 

- Don't have access to the camera and file system in many of the phones so development depends on what you want to do.


 

//========= CDI TSWG MAD Meeting =============//

07Jun2011


 

All, please email rviger@usgs.gov if you are not able to access http://usgs.titanpad.com/cdi-tswg-mad . If you log in, you will be able to help us with note taking (i.e., making sure I don't type your name wrong).


 

Attendees

Dave Greenlee (National Map)

Patty Damon

Mark Kutsko

Brad Williams

Shiji Thomas

Julie Recker

Scott Horvath

Doug Duncan (?)

Mark Hamill

Travis Lawall

Mark Wimer

Jeremy Newsom

Roland Viger

Jon Richards

Pete Cinotto

Abby Benson

Rob Wertz

Dave Govoni

Bob Matthias

Tim Kern

Robert Swanson


 

[see notes just below the agenda text]


 

Agenda:


  • Briefly review MAD goals with new attendees. If PDE community members are present, discuss goals of MAD and PDE and try to get consensus on a common purpose group.  (15 minutes)


 

PDE Goals:


  • Information about policy/publication <-- Scott H.


  • Best practices for mobile dev


  • make available Resources: source control (code sharing)


  • Build a case for DOI to sign TOS w/ Google, Apple

There are repos available: cr.usgs.gov and then the sciencebase repo (for non-USGS)


 

Enough overlap between PDE and MAD to combine the two groups


 

Terms of service: What does it mean for Apple or Andoid SDK, Appstore ?

TOS for using the Apple SDK and then also another for AppStore.


 

How to promote USGS visual identity, come up with a model to get credit.


 

CDI workshop discussion session: discuss how to accomplish this goal.


 

Plan for reaching out to third party developers -- page on wiki for gathering ideas.


 

-----------------------------------------------------------


 

Best practices for QR code,


 

Action: Review goals of PDE and MAD and come up with a combined group goal.


 

USGS Publishing process: need details.


 

Looking into other DOI agencies to see how they have launched native apps. -- citizen science mobile apps. BLM. NPS.


 

http://whatsinvasive.com/


 

http://www.dmg.gov/index.php


 
 

Discussion/Question/Issues:

CDI: management driver or grass roots?

Sponsor : Kevin G. Lot of work going on at grass roots level, and it's a combination.


 

Central repository for services/apps approved by USGS/DOI?


 

Action: Get in formation from Scott H. regarding these services/apps. -- provide DOI and PDE URLs to MAD.


 

CDI is a Community of Practice -- a grass roots learning/knowledge sharing environment sanction by management. -- not strongly top down by design -- place to do your homework and where the informatics R & D takes place


 

Scott Horvath mentioned a worry about people going straight from the idea to production without putting the necessary steps inbetween -- group is maybe too new for this part of the discussion right now

 - Where do we get this information

 - Is there a place to find this information- resource on DOI internal site- have a list put together for USGS


 

Mobile app dev: operational direction


 

  • Mention CDI workshop in August (15 - 19) -- MAD will be most likely doing a presentation and/or a poster and perhaps hold discussion sessions. (15 minutes)


 

  • Ideas for discussion sessions during workshop?


 

  • Review mobile application inventory and see how to


  • Get broader participation from USGS developers to get a more comprehensive inventory (10 minutes)


  • Ideas on how to reach across USGS? -- "data call lite" pointing to the MAD survey; create knowledge base(s)


  • Session : promote at CDI to get people to submit their apps.


  • Showcase existing apps at the CDI workshop (15 minutes)


  • Ideas on how to do that?


  • Review Policy page to get response/volunteers  (5 minutes) <-- if time allows, or else postpone for next meeting


 

Senion leve executinve sponsor : Rich Freizer, Kevin G, -- have Kevin send out a survey.


 

Liason to Fundamental Science Practices.


 

Wiki cleanup.


 
 

- this is a new group.

- what is CDI? Sponsored by CSS, Kevin Gallagher. Not a top-down organization. Tries to discover, build consensus on best practices. Degree to which new work is "forced" to adopt these is not usually debated here. MAD might be special. There are somewhat strong policy implications about developing and distributing applications.

- purpose of group is to establish ideas of best practices to help push these up to policy makers.

- Folks ask for content to be added to MAD wiki. Cross link to Sharepoint from CDI.

- PDE group separate from CDI group? No need for this to happen because there is significant overlap

- PDE group was a lot like what MAD aspires to. Definitely focused on getting our needs up to DOI.

- source.cr.usgs.gov (USGS only)

-sciencebase source also available (open source, available to all) completely different than the publication stuff

- These apps are happening for USGS field work terms of service is platform or publication?

- Apple: 2 terms of service agreements

    -1 to just sign up (pay for) - DOI will not allow anyone to sign (check the box) for this

    -2 one to get the app published in the app store

- Android also has non-govenrment friendly agreements to sign

- Google and android having a little bit of spat right now - nothing getting accomplished

- So right now the app development group can't actually develop any apps

- Trying to compile a list of info to take to Rich Frasier to get DOI to move forward to be able to sign off on them--- but need justification for why this is important --- also reach out to third party developers to allow them to do the apps in the private market with access to our data

  - If USGS is constrained maybe we can open it up to private industry to use USGS data (like water)

  - BUT right now we are not the face for our data because others take it and develop these apps with it -- we need to be the face for our data -- we need to get credit for our data -- but our data is public domain data and should be available for others to use and we should ask for credit -- shouldn't duplicate effort that is already going on out there

- By having a working relationship with private app developers they are more likely to give us credit for our data

 - We need to have a business plan to work with third party app developers

 - Could discuss this at CDI Workshop about how to work with third parties to give us credit for our data- work with us to give us credit -- can have a page on the wiki for gathering ideas about working with third party app developers

- USGS data is public domain data so you can't restrict access to it- basically we can't force third parties to give us credit

- Also need to be looking at citizen science

- If we use web apps then don't have worry about service agreements

- Part of this group is to provide guidance on when to use web apps rather than native apps

- We need to build the information on policy hopefully Scott can help us do that

- We are missing the people who are developing- how do we get these people involved? They will see it as we want to stop what they are doing and that's not true.

- We are building a list of the mobile apps being develop- how do we reach everyone who is developing an app?

- Need best practices on making sure you are sending people to a mobile friendly page (so not just apps)

- Useful to know when an app has already been developed - needs to be built in to the development process

- Can we really compile a list of all the apps using USGS data- seems too big for this group to do - we need a more formal method to address this issue

- We write lots of different programs- how will all of this information apply to those?

- We have survived so far because the source code is published

- Need Privacy Impact Assessment needs to be done (access to personal data on that phone) to determine if there is any private info being collected (ie GPS location of phone) turns into a collection of records that has to be managed - makes DOI hesitant to move forward

- Circular discussion- we are going to have all these internal apps that we have no control over

- We have to build use cases for the native apps to submit to DOI so we don't have to have third party apps all the time- this group could work on that

- Traditional method for this is the publication process - fundamental science practices route

- What's Invasive?- app with the NPS and UCLA; Desert Managers - app for location of desert tortoises- citizen science type of apps for invasive or endangered species - Maybe could talk to the people who (probably .org or .edu that did the development)

- If USGS is not the primary partner then we are just providing the data

- NPS probably just went out and did it without permission- ran in to trouble with Google

- Agreement that we need a session at the CDI Workshop to discuss these topics more fully

- We need an executive sponsor - makes the most sense to go to Kevin - can work with Rich Frasier - Kevin needs to send something out to everyone

- What are we going to do about maintenance of the apps - who pays for those updates? How do we get them done?


 
 

Observation: discussion on "getting credit" for applications should include "branding" and maybe "watermarks" for authoritative data sources - also, we need to have friends outside USGS (and the executive part of the government) in order to communicate with Congress in a mannery that we are precluded from doing.


 
 

//========= CDI TSWG MAD Kick off Meeting=======//

Kickoff Meeting for CDI Tech Stack Work Group:

Mobile Application Development (MAD)

SubTeam, May 17, 2011


 

Attendees (please add details to your name)


 

  • Farial Shahnaz (Reston, BIP) mobile apps


  • Shiji Thomas (Reston, BIP) new to MAD


  • Tenko Dimanov (Reston, BIP)


  • Jean Freeney (Node manager w/NBII, plus other stuff)


  • Jon Baier (Wisconsin Internet Mapping Group) Looking at applications for mobile publishing and web mapping


  • Donn Holmes - (San Diego) lots of experience, PDA (Palm, Windows) connections to databases with Pendragon (older stuff). field data collection with direct sychronization into production ecological database.


  • Abby Benson (Core Science Informatics)


  • Brad Williams (Center for Biological Informatics) Experimenting with Android.


  • Dave Govoni (Enterprise Web Group) interested in mobile web applications for citizen science and field data collections; user interface design/workflow.


  • Alan Vaughn (EWeb) - seeking middleware type support


  • Travis Lawall (Fort Collins Science Center) - experience w/ iPhone.  Appcelerator and PhoneGap.


  • Tim Kern (Fort Collins Science Center) -- lots of mobile and embedded/mobile apps (Droid, iOS, 3rd party API)


  • David Maltby (WiM; Texas Water Science Center) - GIS experience Lots of web development. Developing app for Fish and Wildlife Service on Mobile Phone.  Will use Widgets to be cross-platform compatible.


  • Frank Crenshaw (WRD, Colorado Water Science Center) - PC apps for field data collection(PCFF/ Total Eclipse), some PDA development C++, Android apps


  • Scott McEwen (Core Science Informatics) - Facilitation


  • Roland Viger (Modeling of Watershed Systems) - Facilitation


  • Mark Kutsko (Reston, CCIT)


  • Dave Greenlee, National Geospatial Program - The National Map, Land Cover Product Lead - I am set up in ESRI early adopter program for Android - would like to develop a mobile app that showcases TNM (National Map) data


 
 

Proposed Purpose, Goals, Approach


 

Ideas and comments relative to the ideas and goals Farial presented:


  • Promote adoption of standards and/or best practices


  • Code best practices


  • Usability/interface design best practices


  • Knowledge base needs to include 3rd party apps using USGS data or products.


  • Knowledge base needs to include formal usability studies about basic design/usage patterns for mobile apps (or even a cookbook). Common set of designs or templates for people to use based on format literature on mobile app usability studies. 3 studies have been attached to the MAD intro page.


  • Should use MAD wiki subspace to start building knowledge base


  • Knowledge base: segmenting topics early (mobile apps -- topic divisions based on content/function vs. technical platforms)


  • Apps that deliver data/information to customers (e.g., via RSS or CAP)


  • Apps that are designed to assist in field collection of data/observations


  • Apps that allow on-the-app manipulation and analysis (e.g., "GIS-style")


  • Apps that support community-specific scenarios, e.g., citizen science


  • Wiki-based "Cookbook" to organize and share "best practices", etc., etc.


  • Start adding ideas/concerns about technical challenges into the Technical Issues page.


  • Sharing components / code base -- we should try to leverage as much of the existing code bases as possible


  • Potentially designate someone to look for developments/policies across govt and private sector? --> possibility to fund someone to do this. Funding products such as knowledge base/best practices/training materials that come out of the group.  CDI can potentially augment program and science center funding for broader benefit.


  • Inviting outside speakers to address relevant issues or provide directions.


 

Next Meeting Agenda and Actions


 

  • May 31 at 3p ET


  • Survey USGS to find what is going on as far as mobile dev is concerned -- current status, product inventory.


  • Survey USGS mobile landscape --


  • apps inventory


  • Who (program), what (the app), why (purpose, audience), platform(s)


  • Technology used and any migration/update plans


  • Equipment and/or emulators


  • unmet mobile apps needs


  • Phase 1 of inventory: All apps being developed by USGS programs/developers -- all developer network call to see what is being done. What are the most important fields? [Data, Functionality, Lead Developer / TOC, Platform/Technologies used] and also what people want to see (this is for non-technicals as well). Contact points: Jean, Roland, Scott, Brad.


  • Phase 2: Third party (this could include both govt and private sector but non-USGS) -- apps using USGS data or natural science data and info. <-- Dave Govoni is interested in leading this effort (Eeeek!). Set up a wiki page for non-USGS apps -- define scope and then list resources.