Google Maps V3 45 Degree Imagery in OpenLayers
Posted on October 20, 2011 by Rob Gaston
Using the OpenLayers 2.11 with Google Maps API V3 provides some great new functionality that will lead most users to want to upgrade their existing mapping applications. Not only do you get the latest functionality and imagery from Google Maps, but it also simplifies deployment of your application by eliminating the need for managing API keys.
However, there is a minor ‘gotcha’ in this latest version of the Google Maps API that could cause certain developers a lot of grief which OpenLayers 2.11 will not handle by default. In certain locations, Google Maps API V3 now provides access to 45 degree satellite imagery. “Great!,” you say, but not so fast. The imagery only shows up in certain locations and at certain zoom levels. What’s more, if you don’t specifically disable it, you will always get the 45 degree version of the imagery if it is available. This can create a pretty disjointed user experience when navigating the map, but more importantly it causes any 2D vector layers which you are overlaying on your map to appear improperly registered against the base imagery.
Luckily there is a solution to this issue that is fairly simple to implement. Whenever you add a Google Maps layer to your OpenLayers map, it adds a reference to the Google Maps mapObject that it is using to request the Google Maps imagery. By calling the setTilt method on the map object, we can disable 45 degree imagery for all Google Maps layers, like so:
googleMapsLayer.mapObject.setTilt(0);
Just ensure that this call is deferred until after the layer is added to your map, and you should never see the 45 degree imagery in any of your Google Maps layers.
Tags:
Web Mapping
Software development iterations and data backup for GIS web applications: Part 1
Posted on October 07, 2011 by Vinodh Subramanian
Enterprise GIS web application development is about how to represent your existing data and how to capture new data. Here at Farallon, we have successfully built some very smart geospatial web applications that guide the user in that process.
This post is about how we support the backing up of data for these advanced geospatial apps in order to facilitate the web app development life cycle as well as the production life cycle.
In the early years of GIS web development at Farallon, it was easy to do (or not do) data backup since most projects were single iterations. As the sophistication and mission-critical nature of GIS web apps grew, we starting working on projects that involved multiple iterations, with different developers working on different items of the application/database concurrently.
The above diagram represents the initial architecture to support projects that had multiple iterations.
The steps followed for every iteration were:
- Apply schema and data changes to the database
- Check in the changes as sql files into source control.
- Publish the changes to the server side developers so that they know how to interact with the data e.g. ERD diagram
- Once the iteration is complete label it as such in source control so that there is stable db version that we can roll back to for that iteration.
In the above architecture it's very clear that schema/data integrity become very important so that developers can concentrate on what they are working on and not worry about the application breaking down or not working correctly due to discrepancies in its source (the database).
For example let's take this scenario from our archaeological sites management system.
Let's say there is are three tables: Entity with EntityId, Name and Type as the three columns; EntityGeometry with GeometryId, EntityId, Geometry; and mapping table called EntityAddress with StreetNo, StreetName, City, State and Zipcode.
Developer 1 is responsible for building a web form to fill the Entity and EntityGeometry tables. Developer 2 is responsible for creating the web form to enter the EntityAddress table.
Let's say there is a new requirement for the Entity table schema to include a creation date and retirement date. So the db Developer goes in and adds creation and retirement dates, making them non-null. Developer 1 works on adding the creation/retirement dates to the webform.
It's needless to say that you will have to first add an Entity to the database before you can add an EntityAddress to that Entity. So if Developer 2 tries to test his code for a new Entity, it will break since the webform in source control doesn't have the EntityAddress yet but the database does.
From the above scenario it's clear that the above architecture has its flaws.
In order to resolve that issue a replica of the dev environment was created in each of the developer's development box.
To maintain schema/data integrity schema changes were maintained as .sql files and data was maintained as .dat files in source control. Deployment scripts were created to facilitate the process of backing up schema/data with one click to a bat file.
Lets look at the archeological site management scenario with this new model.
- Db Developer can now make the schema change and data change and run the bat file to back up the changes to the schema/data and check it in to source control.
- Developer 1 can do the update, run the dat file to restore the new schema and data and work on updating the web form to contain the EntityAddress information.
- Developer 2 can wait until Developer 1 completes the web form changes before he gets the latest from source control for both the db and web form changes thus allowing him to test his code without issues.
Some other advantages of the above model are that:
- Developers can, with lots of freedom make changes to the data to test multiple scenarios for the component they are building.
- By separating the dat files into development and production versions it makes it easy to maintain pristine data of the end users without worrying about it during iterations.
Hopefully I was able to convey how this new model has made both the database and server developers life easier. In the next couple of blogs I will take about specific implementations for Postgres and Sql Server.
Tags:
Database
Dynamic FME Workspaces streamline repetitive tasks and create generic spatial processing tools
Posted on July 08, 2011 by Jeff Smith
With the release of FME 2010, Safe Software introduced dynamic workflows which can bring a whole new level of flexibility to FME workspaces. Although dynamic workflows won't be appropriate for every situation, there are many common scenarios where they can make your life a lot easier. Dynamic workflows allow us to create workspaces that are generic, reusable, and require much less maintenance when compared with using non dynamic solutions.
In the past, FME workspaces have been very closely tied to specific datasets. Let me describe a scenario that is just begging for dynamic functionality. Say you need to extract the parcel data for a particular city from a countywide parcel layer and then re-project it. This is a trivial task for the typical FME user. You start by adding a reader for the county parcel layer, and then another for the city boundary. Next you add the clipper to extract only parcels that fall within the city boundary, and the re-projection transformer. Finally you add a writer to save the extracted data. You're done for now....
A week later you get a very similar request, but this time you need to extract streets data for the same city from a countywide streets layer. You think to yourself "simple", open your previous workspace, and then update the reader and writer to point to the streets layer instead of the parcel layer. This solution works fine, but what happens when you start getting this same request for lots of different layers. Many FME users would continue modifying their original workspace, and creating copies that are specific to each of the layers they need to perform the process on. This is fine until someone throws a curve ball and tells you they need all of the extractions repeated and the output data in a different projection.
At this point you can either update all of your data specific workspaces, or you can get dynamic and realize there is an easier solution. The only part of the workspace that you are changing is the feature that is getting read in and written out from the translation. There is no logic within the workspace that is specific to a particular layer's attributes. By using a dynamic reader and writer you can create a single workspace that will be able to perform the clipping and re-projection to any dataset. Centralizing everything into a single workspace can save you a great deal of time and effort. Down the road, if any other general logic needs to be added into the transformation, such as cleanup or validation of the geometry, you will be able to make this change in a single location instead have to update each data specific workspace.
Beyond just streamlining similar, repetitive tasks, dynamic workspaces allow you to create generic processing tools. We recently had a client ask for a way to spatially visualize the results of non spatial database queries from a Business Intelligence (BI) application. This was a very tricky problem because we had no idea what the results of the query from the BI application would look like, and we had to be able to join those results to one of many potential spatial layers. We achieved this through the creation of an FME workspace utilizing dynamic readers and writers, as well as a slew of published parameters to pass in data specific variables at runtime, such as which spatial data to utilize and what column the join should be performed with. (See my FME World Tour presentation FME Server as Geospatial add-on for Business Intelligence Querying" detailing this). Our FME workspace was able to read in any query results produced by the BI application and join the appropriate column with a spatial data layer such as state boundaries or census block groups that was being pulled from a spatial database. The solution is very generic in nature and could be used for any CSV data that contains attributes that can be associated with spatial data. Using FME to tackle this type of problem would simply not be feasible without dynamic workspaces!
Tags:
FME
Section 508 accessibility for geospatial and web mapping applications
Posted on June 09, 2011 by Dennis Wurthrich
I recently received a question regarding Section 508 accessibility issues for implementations with GeoServer.
Section 508 refers to a a federal law mandating that all electronic and information technology developed, procured, maintained, or used by the federal government be accessible to people with disabilities.
Section 508 requirements pose significant challenges for geospatial and web mapping applications. These applications are visual, interactive and dynamic in nature and are difficult to enable for full accessibility. GeoServer is not unique in this regard. For example, screen readers are not able to accurately describe the full content of a map generated on-the-fly.
Currently the best ways we have found to handle accessibility for geospatial data and maps are adding alternate text fields or tooltips, using text-based tabular information for critical map coordinates matched to descriptive text, or if viable using a video with synchronized captions. It all boils down to user interface - finding intelligent, alternate ways to represent dynamic, visual information. One interesting side note: solutions that successfully design for accessibility will also improve search engine optimization.
I am interested in any research on practical methods and technologies for handling accessibility in geospatial mapping applications. If you have any relevant information on this topic, please comment on this blog.
Tags:
Web Mapping
