210 likes | 301 Views
City of Medford. A road construction application. Public Works Department Goal. Notify citizens and media of road hazards and impediments. Audience: TV Newspapers Citizens City Staff Public Safety. The old system. A manually managed list Bulk emails sent to all users
E N D
City of Medford A road construction application
Public Works Department Goal • Notify citizens and media of road hazards and impediments. • Audience: • TV • Newspapers • Citizens • City Staff • Public Safety
The old system • A manually managed list • Bulk emails sent to all users • Must call department to be added or removed • No mapping, just a description
What can GIS do for you? • Standardize notifications • Capture data • Create maps of work zones • Daily Summary Map • Daily Update • News Release • Enable citizens to sign up • Create output in KML • Consistent URL for users to access road construction info
So, which API? • Flex? • We are a .NET shop go with your strengths No flex!
So, which API? • Silverlight? • We love the functionality and rich user experience • But … this is an internal only application • We want to stand up quickly No silverlight!
So, which API? • Javscript? • I hate Javascript! • No intellisense or real debugging in Visual Studio • Javascript can get sloppy ... compiled code is organized • I love Javascript! • ArcIMS got us all very comfortable with Javascript • Javascript is fast • JQuery and Dojo are awesome • $ajax() calls to services are so fast and easy • Asynchronous REST calls keep things moving • UI Libraries get us most of the user experience that we want
How it is used(City website) How it is used(Events) How it is used(MedfordMaps) Video News Release PDF Daily Update PDF
Console application DNA of the System Web application Server Object Extension Medford Maps
Web application • MVC2 • LINQ to SQL • JQuery • Dojo • Javascript API • SOE LINQ to SQL Databases REST SOE Public Website ArcGIS Server
Console application • SOAP SDK • SOE • System.Data • Scheduled task Databases SOAP SOE ArcGIS Server Public Website
LINQ to SQL Issues • Joins! • I typically design my joins in SQL Server Mgmt Studio … easy SQL Looks something like this: SELECT dbo.mp_Users.UserID,dbo. mp_Users.SiteID, dbo.mp_Users.Name, dbo.mp_Users.LoginName, dbo.mp_Users.LoweredEmail, dbo.mp_Users.PasswordQuestion, dbo.mp_Users.PasswordAnswer, dbo.mp_Users.Pwd, dbo.mfr_MailingListUser.MailingListID, dbo.mfr_MailingLists.MailingListName, dbo.mfr_MailingLists.ApplicationName, dbo.mfr_MailingLists.IdentifierName FROM dbo.mfr_MailingLists INNER JOIN dbo.mfr_MailingListUser ON dbo.mfr_MailingLists.MailingListID = dbo.mfr_MailingListUser.MailingListID INNER JOIN dbo.mp_Users ON dbo.mfr_MailingListUser.UserID = dbo.mp_Users.UserID In LINQ it becomes something like this: var mailingListUsers = from u in db.mp_Users from mlu in u.mfr_MailingListUsers join ml in db.mfr_MailingLists on mlu.MailingListID equals ml.MailingListID select u; return mailingListUsers;
LINQ to SQL Issues • Database Design • LINQ to SQL strongly typed objects are really nice to use • Though, I am finding that I like the Silverlight / WCF model (as I work more with Silverlight) • My database design techniques need to change up a bit • Focus more on business objects than on normalization (not mutually exclusive, but can be different) • I have always avoided trying to create database objects that look like "objects", rather I just think in terms of how to normalize. • Now is the time to rethink my database design strategies and think about the database as an active participant in my application, rather than simply a storage mechanism for the data ... am still sorting this idea out.
MVC Issues • Getting accustomed to the MVC way of doing things • Dropdown lists • This was a really kind of odd thing for me to get a handle on. It is seemingly trivial, but took some adjustment to figure out public class ContractorRepository { public IQueryable<Contractor> ReturnAllContractors() { return db.Contractors; } } ----- public class ProjectsController : Controller { ContractorRepository contractorRepository = new ContractorRepository(); ... public ActionResult Create() { SelectList contractors = new SelectList(contractorRepository.ReturnAllContractors(), "ContractorID", "Name", project.ContractorID); ViewData["Contractor"] = contractors; } }
MVC Issues • Serializing JSON • This was eventually another simple solution … eventually. • As with most problems in MVC, there is always an answer public JsonResult GetProjectGroups() { var projectGroups = from p in constructionProjectGroupRepository.ReturnAllProjectGroups() select new { ConstructionProjectID = p.ConstructionProjectID, ConstructionProjectGroupID = p.ConstructionProjectGroupID, StartDate = (DateTime?) p.StartDate, EndDate = (DateTime?) p.EndDate, ReleaseDate = (DateTime?) p.ReleaseDate, DateEmailSent = (DateTime?) p.DateEmailsSent, AllDay = p.AllDay }; return Json(projectGroups, JsonRequestBehavior.AllowGet); }
MVC Issues • Testing and Mail • This application uses Active Directory to get many of the email recipients. • Debugging the mail is a huge pain • There have been situations where random settings at the network level have prevented users from receiving emails • Also, how users are stored in Active Directory is an issue when searching for valid Active Directory users • Normal users = 512 • Users who don’t need a password = 544 • Not a good test for valid users depending on how your AD is set up.
SOE Issues • There are some large hurdles related to converting to Server Object Extensions • The difference between wrapper functions and business functions • Wrapper functions handle to communication back to the client • Business functions do the work … called from wrapper function (of the same name) • Registering the SOE • We had some registration issues • Our servers (and dev machines) are 64 Bit • The short story … we needed to compile to 32 bit .. long story was longer • Not a whole lot of really good documentation • Or in some cases, too much disparate documentation • SOE design on the ArcGIS Server • Really designing how SOE’s relate to services on our server is still evolving • Probably need to spend more time with Property Pages • Awesomeness • No Server Context • All ArcObjects – so very nice! • Once you get beyond the SoapMessaging stuff, it is just plain old ArcObjects • Steep learning curve initially, but once you get over the hurdles it is smooth sailing
ESRI Support Issues • ESRI Support is phenomenal! • We buy developer support • Am the only developer in our group, so it is good to have someone to help me see things differently • Get pointed in the right direction • Quickly escalate issue if necessary • I enjoy talking with them and just working through issues with them • Best thing from ESRI we have ever purchased! • Shoutouts (for help with SOE configuration) • Xuening • Rahat • Sumedha • Nagendra • Shoutouts (for general help) • Yamini • Nakul • Thanks ESRI Support!
Thanks! </presentation> David Renz http://www.medfordmaps.org / http://ci.medford.or.us david.renz@cityofmedford.org