Matt Gregory demonstrated some scripts he's developed to work with Google Maps and Google Earth. It was way cool. See Matt’s PowerPoint file for guidance on how to do these things.
Kuuipo attended. This was a discussion of the orthoimagery framework data for Oregon, with questions of how frequently and at what resolution do agencies need imagery? Some want frequent imagery at a lower resolution, while others want a higher resolution at less frequent intervals. There was also an update on the process of flying LiDAR for the entire state.
In response to a question, Kuuipo said that the Imagery Explorer website will eventually have historical orthophotos – 1996 and 2001.
Forestry Computing are planning to do away with specific database use costs for SQL Server, SDE, etc., and distribute those costs across all users. Cautionary tale: the HJA site got hacked and the hackers got to Rocky (SQL) that way.
Dave is planning to attend this year. Theresa may attend. Kuuipo wants to send someone from the Valley Library. Will the UC be any good? Will 9.3 be out yet?
Kuuipo and folks from Valley Library are doing a Spatial Data Explorer workshop, introducing this new website for serving state of Oregon GIS data.
KML/Google Earth (starting with scripts from Matt this week)
For the Geoprocessing Group, Matt has been in touch with Brian at Alsea Geospatial, who knows Corey who is good at open source C# integration. Internet mapping was also a possible topic. The Valley Library uses Moxy Media as the front end for their ArcIMS sites.
Minor rumors about an impending release. Little more. Some discussion of why we use ESRI. Some of the programmers in the group felt like ArcObjects is so clunky and hard to program that it’s not preferable. With Google making spatially integrated data more accessible to the masses, this may become increasingly relevant.
If anyone uses NRCS soils data via WFS or WMS servers (that can be queried spatially), let them know this is valuable. They are considering discontinuing the service.
Framework data, definition: Statewide base GIS layers, which have had standards developed so that data created by different counties/municipalities is consistent.
This is what I referred to about encrypting passwords in the SDMG meeting today. There may be better ways of doing this. I make no warrantee expressed nor implied. This works for us because we can use the same web.config on both test and production machines, so long as we set the registry on both machines to contain the encrypted credentials of the domain user.
In web.config, you can refer to encrypted credentials stored in the registry: You can use this in
userName="registry:HKLM\SOFTWARE\mykey\identity\ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\mykey\identity\ASPNET_SETREG,password"
First you need to run the utility, aspnet_setreg.exe, to create and encrypt the the keys.
You can find this utility in the Visual Studio distribution, or you can search microsoft site for it.
C:\bin> aspnet_setreg.exe -k:SOFTWARE\mykey\identity -u:"domain\user" -p:"passwd"
The resultant keys themselves should have the correct DACLs. I think this is what is needed.
Administrators:F
SYSTEM:F
CREATOR OWNER:F
ProcessAccount:R