Planet Geospatial

GeoSolutions' Blog


GeoSolutions is looking for talented people to fill a couple of positions which would mainly involve designing, implementing testing web-based geospatial applications as well as providing support for the Open Source projects we are involved in.

Here below some additional details:

Support Engineer
This position will mainly focus on having our clients receive the support they need in time and with the quality level they expect from us.  The ability to work and communicate clearly in a fast-paced environment is essential since the Support Engineer will be the main point of contact between clients and developers and as such he will be responsible for mediating and coordinating clients' needs. Customers' satisfaction is going to be your mission!

Main Responsibilities are as follows:
  • Create documentation and trainings
  • Play the Q&A Engineer role when needed
  • Monitor quality and SLA levels for support accounts. Manage and improve support procedures as needed
  • Coordinate with development team to get updates on ongoing as well as planned planned enhancements for the products
  • Interface with development and support teams from GeoSolutions as well as customers to ensure resolution of all customer calls
  • Periodically report status and strategic recommendations from clients to GeoSolutions leadership

Qualifications are as follows:
  •  1 year in technical support management, including personnel management
  •  Familiarity with CRM or issue management systems 
  • Working knowledge of GeoServer
  • Good Knowledge of most important OGC specifications and concepts (WMS, WFS, WCS, coverage, etc...)
  • Working knowledge of OpenLayers is a plus
  • Working knowledge of GeoNetwork is a plus

Front End Developer
This position would mainly involve designing and implementing web-based geospatial applications as well as providing support for the Open Source projects we develop.
Qualifications are as follows:
  • Working knowledge of OpenLayers and GeoExt
  • Working knowledge of frameworks like JQuery,  Ext-JS 
  • Working knowledge of HTML5 and development of mapping webapp for the mobile world
  • Working knowledge of frameworks like LeafLet, Recline-JS is a plus
  • Knowledge of web development with Python is a plus
  • Knowledge of Java (JEE and JSE) is desirable but not necessary
  • Knowledge of GeoServer is desirable but not necessary
  • At least 1 year of experience
  • Being fluent in English, both written and spoken
What we offer
We can offer a variety of contracts but, please, notice that our intention is to establish a long term relationship, although as a temporary solution we do accept freelance consultants.
Working remotely is an option we envisage, although we will give priority to candidate closer to our office.

Please send a detailed resume together with a letter of presentation at jobs_at_geo-solutions.it.

The GeoSolutions team,

LiDAR News—Nikon’s CMM Horizontal Laser Scanner Arm

the automotive industry is probably the most advanced of any when it comes to the use of laser scanning. Continue reading →

Click Title to Continue Reading...

Directions Magazine—TruePosition Tackles Indoor Locating

TruePosition released testing results of its indoor location technology in April. These tests put the company squarely into the Federal Communication Commission explorations of indoor locating for emergency response. Directions Magazine interviewed Rob Andersen, chief technology officer of TruePosition, about the company’s technology and plans for the future.

Spatial Law and Policy—Posts/Editorials from recent conference on a Location-enabled society

A video of the recent conference on The Legal and Policy Framework for A Location-enabled Society will be available shortly. In the meantime, I would like to thank three of the speakers who wrote about the program in blog posts and editorials for contributing to the discussion on these important issues.

Nancy Colleton (Institute for Global Environmental Studies)   Location Data Reveals Our Changing Planet

Geoff Zeiss (Between the Poles) Privacy and Personal Geographic Data

Valerie Shuman (Shuman Group) Location-enabled Society Conference

Cameron Shorter—Will OGC’s standards meet government purchasing guidelines?

Taxonomy upgrade extras: 
ogc
OSGeo
osgeolive

In what has become the OGC’s most contentious vote to date, OGC members are being asked whether the proposed "Geoservices REST API" should be accepted as an OGC standard. A summary of concerns are listed in an Open Letter from the Open Source Geospatial Foundation (OSGeo) to the OGC. However, the crux of contentions hinge around the definition of an Open Standard and whether the "Geoservices REST API" qualifies as one.
When measured against government’s policy drivers of interoperability, fair competition, and economical use of government funds, the evidence is overwhelming. "Geoservices REST API" fails on all accounts. In fact, we should be questioning why our OGC processes haven’t identified and then addressed these issues much earlier.

Background

As background, the "Geoservices REST API" describes the interface to a dominant vendor’s web service (ESRI’s ArcGIS Server), and overlaps substantially with OGC’s existing suite of web service standards.

What is an Open Standard?

Most government purchasing guidelines, such as the United Kingdom Open Source, Open Standards and Re­Use: Government Action Plan, now include clauses such as:

The Government will use open standards in its procurement specifications and require solutions to comply with open standards. The Government will support the development of open standards and specifications.

Consequently, government contracts typically specify OGC standards when purchasing spatial systems. This places a responsibility on the OGC and OGC members to protect government policy when selecting and defining the OGC standards baseline.
Superficially, the "Geoservices REST API" meets the European Interoperability Framework minimal definition of a standard:

  • The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).
  • The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.
  • The intellectual property - i.e. patents possibly present - of (parts of) the standard is made irrevocably available on a royalty-free basis.
  • There are no constraints on the re-use of the standard.

However, the "Geoservices REST API" falls short of addressing government policy drivers for the creation of standards. These are summarised in the Guideline on Public Procurement of Open Source Software, written for the European Commission:

Public sector consumers of software have an obligation to support interoperability, transparency and flexibility, as well as economical use of public funds. When it comes to public procurement, the principles applied to the public sector require them to support (and certainly not to harm) competition through their procurement practices. ...
Good practice eGovernment services should provide access based on open standards, and in particular, never require citizens to purchase or use systems from specific vendors in order to access public services: this is equivalent to granting such vendors a state-sanctioned monopoly.

Lets address these issues point by point.

Costs and Interoperability

Regarding when to create new standards, the United States Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software has the following advice:

... use/modify/create open standards, in that order.

Unfortunately, the "Geoservices REST API" would create new standards rather than use and/or extend existing OGC web services. Emphasis on reuse of standards is important for increasing interoperability, as duplication of standards typically results in:

  1. Implementation costs to support multiple standards increases.
  2. Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
  3. Sponsors (such as governments) who require compliance with standards will discover that applications don't communicate together, due to applications supporting different standards that essentially do the same thing.

Costs increase, interoperability decreases.

Fair competition

ESRI’s ArcGIS Server is currently the only server which provides a full implementation of the "Geoservices REST API", as you would expect when an API is derived directly from a product. As such, if the "Geoservices REST API" were to be included in the OGC baseline, and government contracts continue to reference the OGC baseline in contracts, then governments would be giving one vendor a significant market advantage while other vendors wear the cost of developing matching implementations for the proposed standard.

Further, ESRI may continue to use its market dominance to promote use of the "Geoservices REST API" at the expense of existing OGC web services. (As described in ArcGIS Server documentation, support for OGC’s W*S services are disabled by default while GeoServices REST and KML are enabled).

Where are the Open Source implementations?

Another test for identifying open standards is defined by the United States Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software:

Verify that the standards used are open; a simple test for openness is to determine if the standard is implemented by open source software.

Currently, very little open source has been developed to support the "Geoservices REST API" and there is wide opposition to the proposed standard from the Open Source community.
Open Source implementations referenced by proponents of the "Geoservices REST API" include immature implementations, partial implementations and a library application. That is: a roadmap document for GeoServer, a sandbox implementation of an Openlayers client, a 52North SOS extension to ArcGIS Server and the GDAL translation library.
By comparison, there are multiple production grade, client and server, open source implementations, which cover the full breadth of existing OGC standards, which have matured over the past decade, and there are open source reference implementations for most (all?) current OGC standards.
So by the Open Technology Development definition, The "Geoservices REST API" hasn’t yet reached the maturity of an Open Standard.

Where are OGC’s gatekeepers?

There are 481 OGC members, with close to 100 of them with voting privileges, yet regularly, less than 40% of these voting members actually vote on proposed standards. This is a concern if these members are being relied upon to uphold OGC values, and we should question why voting is so low. A key factor in low voter turnout is likely the complexity and volume of material voters need to understand in order to make an informed decision. Gatekeepers just don’t have the time to be abreast of all the issues, and current standards are hard to read. The increase in the breadth and application of OGC standards has led to a stronger need for integration of standards, architectural overviews, and clearer implementation guidelines.
Maintaining and verifying quality best addressed by defining and following development and validation processes, and OGC processes should be improved to match the complexity of the systems they represent. In particular, OGC should revisit goals and requirements for quality standards, then resource technical writers and reviewers to work against such requirements. Approving a standard is therefore simplified to verifying the process is valid and has been followed. This would require OGC sponsorship priorities changed to provide greater emphasis on quality over quantity of standards.

A blueprint for moving forward

Lets expand on the steps involved in deciding on the value of a standard:

  1. Governments policies should embody government best practices. Many countries have already taken this initiative.
  2. Standards organisations, should embrace such government policies.
  3. A clear definition of an "open standard" is required, which addresses government policy requirements of interoperability, fair competition, free access to government services, and economical use of public funds. This should be expanded into clear guidelines to be applied by OGC Gatekeepers and standards developers. The OGC should revisit the "open standards" definition, and in particular, ensure the definition extends beyond the technical to include policy implications.
  4. Suitable training should be available to OGC Gatekeepers and implementers of OGC based solutions. LISAsoft provides an Effective Software Selection course which closely aligns with such training requirements.
  5. The OGC and OGC sponsors should consider realigning priorities. In particular:
  • Place a greater emphasis on quality over quantity of standards. This includes: harmonising competing standards, improving quality of writing to support understandability and implementability, and extend testing to verify standards are implemented correctly.
  • Provide simple and clear descriptions of standards. The OSGeo-Live project has addressed similar issues by providing a concise one page project overview, plus a ten minute quickstart, translated into 11 languages, for fifty of the best geospatial open source applications.

Summary

As the success of the OGC increases, the OGC will need to be mindful of business and policy implications associated with adopting established interfaces as standards. Specifically, accepting the currently proposed "Geoservices REST API" as a standard will have detrimental impacts on interoperability, fair competition, and economic use of public funds. Instead, the positive aspects of the "Geoservices REST API" should be harmonised and incorporated into the existing OGC baseline of standards. Also, as the breadth of technology covered by OGC standards increases, it is becoming more difficult for gatekeepers to monitor the quality of these standards and consequently it is becoming more important to focus on quality and understandability of these standards. In moving forward, the OGC membership should revisit OGC priorities, and consider placing a greater emphasis on quality over quantity.

LISasoft Blog—Will OGC’s standards meet government purchasing guidelines?

Taxonomy upgrade extras: 
ogc
OSGeo
osgeolive

In what has become the OGC’s most contentious vote to date, OGC members are being asked whether the proposed "Geoservices REST API" should be accepted as an OGC standard. A summary of concerns are listed in an Open Letter from the Open Source Geospatial Foundation (OSGeo) to the OGC. However, the crux of contentions hinge around the definition of an Open Standard and whether the "Geoservices REST API" qualifies as one.
When measured against government’s policy drivers of interoperability, fair competition, and economical use of government funds, the evidence is overwhelming. "Geoservices REST API" fails on all accounts. In fact, we should be questioning why our OGC processes haven’t identified and then addressed these issues much earlier.

Background

As background, the "Geoservices REST API" describes the interface to a dominant vendor’s web service (ESRI’s ArcGIS Server), and overlaps substantially with OGC’s existing suite of web service standards.

What is an Open Standard?

Most government purchasing guidelines, such as the United Kingdom Open Source, Open Standards and Re­Use: Government Action Plan, now include clauses such as:

The Government will use open standards in its procurement specifications and require solutions to comply with open standards. The Government will support the development of open standards and specifications.

Consequently, government contracts typically specify OGC standards when purchasing spatial systems. This places a responsibility on the OGC and OGC members to protect government policy when selecting and defining the OGC standards baseline.
Superficially, the "Geoservices REST API" meets the European Interoperability Framework minimal definition of a standard:

  • The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).
  • The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.
  • The intellectual property - i.e. patents possibly present - of (parts of) the standard is made irrevocably available on a royalty-free basis.
  • There are no constraints on the re-use of the standard.

However, the "Geoservices REST API" falls short of addressing government policy drivers for the creation of standards. These are summarised in the Guideline on Public Procurement of Open Source Software, written for the European Commission:

Public sector consumers of software have an obligation to support interoperability, transparency and flexibility, as well as economical use of public funds. When it comes to public procurement, the principles applied to the public sector require them to support (and certainly not to harm) competition through their procurement practices. ...
Good practice eGovernment services should provide access based on open standards, and in particular, never require citizens to purchase or use systems from specific vendors in order to access public services: this is equivalent to granting such vendors a state-sanctioned monopoly.

Lets address these issues point by point.

Costs and Interoperability

Regarding when to create new standards, the United States Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software has the following advice:

... use/modify/create open standards, in that order.

Unfortunately, the "Geoservices REST API" would create new standards rather than use and/or extend existing OGC web services. Emphasis on reuse of standards is important for increasing interoperability, as duplication of standards typically results in:

  1. Implementation costs to support multiple standards increases.
  2. Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
  3. Sponsors (such as governments) who require compliance with standards will discover that applications don't communicate together, due to applications supporting different standards that essentially do the same thing.

Costs increase, interoperability decreases.

Fair competition

ESRI’s ArcGIS Server is currently the only server which provides a full implementation of the "Geoservices REST API", as you would expect when an API is derived directly from a product. As such, if the "Geoservices REST API" were to be included in the OGC baseline, and government contracts continue to reference the OGC baseline in contracts, then governments would be giving one vendor a significant market advantage while other vendors wear the cost of developing matching implementations for the proposed standard.

Further, ESRI may continue to use its market dominance to promote use of the "Geoservices REST API" at the expense of existing OGC web services. (As described in ArcGIS Server documentation, support for OGC’s W*S services are disabled by default while GeoServices REST and KML are enabled).

Where are the Open Source implementations?

Another test for identifying open standards is defined by the United States Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software:

Verify that the standards used are open; a simple test for openness is to determine if the standard is implemented by open source software.

Currently, very little open source has been developed to support the "Geoservices REST API" and there is wide opposition to the proposed standard from the Open Source community.
Open Source implementations referenced by proponents of the "Geoservices REST API" include immature implementations, partial implementations and a library application. That is: a roadmap document for GeoServer, a sandbox implementation of an Openlayers client, a 52North SOS extension to ArcGIS Server and the GDAL translation library.
By comparison, there are multiple production grade, client and server, open source implementations, which cover the full breadth of existing OGC standards, which have matured over the past decade, and there are open source reference implementations for most (all?) current OGC standards.
So by the Open Technology Development definition, The "Geoservices REST API" hasn’t yet reached the maturity of an Open Standard.

Where are OGC’s gatekeepers?

There are 481 OGC members, with close to 100 of them with voting privileges, yet regularly, less than 40% of these voting members actually vote on proposed standards. This is a concern if these members are being relied upon to uphold OGC values, and we should question why voting is so low. A key factor in low voter turnout is likely the complexity and volume of material voters need to understand in order to make an informed decision. Gatekeepers just don’t have the time to be abreast of all the issues, and current standards are hard to read. The increase in the breadth and application of OGC standards has led to a stronger need for integration of standards, architectural overviews, and clearer implementation guidelines.
Maintaining and verifying quality best addressed by defining and following development and validation processes, and OGC processes should be improved to match the complexity of the systems they represent. In particular, OGC should revisit goals and requirements for quality standards, then resource technical writers and reviewers to work against such requirements. Approving a standard is therefore simplified to verifying the process is valid and has been followed. This would require OGC sponsorship priorities changed to provide greater emphasis on quality over quantity of standards.

A blueprint for moving forward

Lets expand on the steps involved in deciding on the value of a standard:

  1. Governments policies should embody government best practices. Many countries have already taken this initiative.
  2. Standards organisations, should embrace such government policies.
  3. A clear definition of an "open standard" is required, which addresses government policy requirements of interoperability, fair competition, free access to government services, and economical use of public funds. This should be expanded into clear guidelines to be applied by OGC Gatekeepers and standards developers. The OGC should revisit the "open standards" definition, and in particular, ensure the definition extends beyond the technical to include policy implications.
  4. Suitable training should be available to OGC Gatekeepers and implementers of OGC based solutions. LISAsoft provides an Effective Software Selection course which closely aligns with such training requirements.
  5. The OGC and OGC sponsors should consider realigning priorities. In particular:
  • Place a greater emphasis on quality over quantity of standards. This includes: harmonising competing standards, improving quality of writing to support understandability and implementability, and extend testing to verify standards are implemented correctly.
  • Provide simple and clear descriptions of standards. The OSGeo-Live project has addressed similar issues by providing a concise one page project overview, plus a ten minute quickstart, translated into 11 languages, for fifty of the best geospatial open source applications.

Summary

As the success of the OGC increases, the OGC will need to be mindful of business and policy implications associated with adopting established interfaces as standards. Specifically, accepting the currently proposed "Geoservices REST API" as a standard will have detrimental impacts on interoperability, fair competition, and economic use of public funds. Instead, the positive aspects of the "Geoservices REST API" should be harmonised and incorporated into the existing OGC baseline of standards. Also, as the breadth of technology covered by OGC standards increases, it is becoming more difficult for gatekeepers to monitor the quality of these standards and consequently it is becoming more important to focus on quality and understandability of these standards. In moving forward, the OGC membership should revisit OGC priorities, and consider placing a greater emphasis on quality over quantity.

AnyGeo—Caterpillar Announces Cat B15 Rugged, Android Smartphone

WOAH, this is just downright awesome! The annual CTIA wireless industry show is on this week in Vegas and as usual, there’s plenty of cool announcements coming out of the mobile ecosystem. One announcement that really got my attention comes … Continue reading →

VerySpatial—GIS and Oklahoma Disaster

Many geospatial professionals, such as those on the GIS Stack Exchange, have asked what they can do with geospatial technologies to help in the aftermath of the tornadoes in Oklahoma or for other disasters.  There are several crisis maps online including Google’s Oklahoma Crisis Map and ESRI’s Public Information Map.  The American Red Cross has the Safe and Well Communication site and a map of available shelters.   The Federal Emergency Management Agency (FEMA), the NOAA National Weather Service, and other

There are organizations that do crisis mapping, the most well-known being the URISA GIS Corps. Many times local areas have their own crisis mappers organizations which work with local geospatial groups, first responders, and municipalities.  The volunteer profile for Sean Bohac from RECON Environmental gives a good insight into what it is like to be a GIS volunteer in a disaster situation. Anahi Ayala Iacucci talks about other types of crisis mapping on her Diary of a Crisis Mapper website.

Crisis mapping is often an overlap of  existing geospatial infrastructure, when available, and disaster response by geospatial professionals and neogeographers. The National Academy of Sciences has an open book called, “Successful Response Starts with a Map: Improving Geospatial Support for Disaster Management (2007)” by the Board on Earth Sciences and Resources (BESR).  The City of Moore, Oklahoma publicly available interactive map includes tornado damaged parcels from 2003 and many utilities including fire hydrants, which many towns have not located and mapped yet. They also ask that donations be made through The Red Cross.

I wasn’t able to locate any information related to directly related volunteer efforts, so please feel free to post any information you might have. Thank you.

 

 

The Big Blue Thread—Rerun of Twister TV

By Jeffery Robichaud

I was saddened just like most of you to see the footage from yesterday’s events in Moore, Oklahoma.  Several years ago I posted this article on EPA’s main Greenversations Blog.  Two years ago our Region experienced our own devastation to the south in Joplin, Missouri.  Tornadoes are serious stuff.  Make sure you and your family are prepared especially if you live east of the Rockies as they can hit most anywhere (great visualization from John Nelson of uxblog.idvsolutions.com).

tornadotracks

EPA has a broad and powerful mission to protect human health and the environment. We often think of this in the context of human impacts on the environment, but sometimes it is the other way around.

In Kansas City, a threat to our well-being rears its head every spring. I could tell it arrived the other night when I flipped on the TV to watch LOST and the screen lit up with red and green splotches over a map. It was storm season again and meteorologists had pre-empted Must-see TV for Twister TV with the fervor of election-night coverage or the latest celebrity car chase.

photo of a home demolished by a twisterIt was our first warning of the season, and my wife and I scooped up the kids and raced down into the basement. The all clear came, but another siren sounded an hour or so later. We repeated the drill (this time with sleeping children) and trudged to bed after another all clear. Not until the morning did we learn that two twisters touched down next to our local drug store. Five years prior a tornado ripped through Kansas City just a mile south of our house (my wife ever the wiser of the pair dragged me inside reminding me that I was now a dad). Sadly this was reinforced two years ago when our good friends lost their home in Springfield, Missouri to a twister. They had a newborn, which, as my friend told me, was the only reason they got off the couch and ran to the closet that saved their life.

Last year (edit: 6 years ago now) was a rough one for natural disasters in our Region. Everyone remembers the devastation that occurred in Greensburg, Kansas. At EPA, we get called in to assist with public health and environmental problems in the aftermath of events like the tornado in Greensburg or the flooding that struck Coffeyville, Kansas. It is heartbreaking to hear the stories of our neighbors, especially the occasional ones who ignored warnings.

Yes, newscasters tend towards exaggeration and embellishment to ensure rapt audiences, but don’t let that overwhelm the importance of heeding the underlying message. Next time you are faced with a flood, fire, hurricane, or tornado warning make sure you get yourself and family to a safe place instead of watching TV. And if anybody in Kansas City needs to know what happened on LOST let me know… I DVR’d the re-broadcast.

 

Jeffery Robichaud is a second generation EPA scientist who has worked for the Agency since 1998. He currently serves as Deputy Director of EPA Region 7′s Environmental Services Division.

AnyGeo—The Nokia Lumia 925 #switch Launch Video

Nokia launched the Nokia 925 in an official PR launch event last week (May 14, 2013) in London, sadly the invite to yours truly @gletham seems to have  gone missing ;0) but regardless, here’s a cool video from the event … Continue reading →

GeoSolutions' Blog—Fun with MapStore: Italian UNESCO Sites as OpenData


Dear All,
there days the Italian UNESCO Sites of interests have been released as OpenData via this portal (NOTICE; we were not involved :)).

The data can be downloaded, there are WMS and WFS end endpoints available (using GeoServer), and there is a small webgis based on OpenLayers (which could actually be improved a litlle bit ;) ).
Well, OpenData + Open Services, this is really nice so I thought I could share a map I created with the cloud version of MapStore the same data with proper querying capabilities and so on.

So there you go, here below you can find a pretty simple map that just shows our UNESCO items, you can embed it in your site with the following HTML code:

<iframe height="400" src="http://mapstore.geo-solutions.it/mapcomposer/viewer?locale=en&amp;bbox=-1851508.8592676,4102979.8193213,4351508.8592676,7429519.2898291&amp;mapId=356" style="border: none;" width="500"></iframe>

 Next steps would be customizing the info boxes and probaly adding more  markers (get some info here) but I guess for the moment this is enough from us :). Ah yeah, I would probably also make good use of the buffer WMS parameter of configuration to make sure symbologies don't get cut in tiled development, here is some additional infomation.





Visit our online demo or download the MapStore binary, read the Quick Start guide and start to create and share your own maps. If you need more info, please check to the complete documentation wiki.

If you have questions or if you just want to talk to us about using our tools in your project, please, subscribe to the mailing list here. In any case, do not hesitate to contact us.

Happy mapping to everybody!

The GeoSolutions team,

Gary's Bloggage—Welcome To The United States; A Cold War Tourist Map For Soviet Visitors

In the mid 1950s America and Russia were in the middle of the game of oneupmanship, with added nuclear weapons, that was the Cold War. Despite the uneasy detente between the two countries, if you were one of an elite group of Soviet citizens you were actually able to visit the United States. But not all of it. Large swathes of the US were closed to prospective Soviet tourists.

ProhibitedMapFinal.jpg.CROP.article920-large

What makes this map interesting is not so much the slice of relatively recent world history that it portrays but more of the questions it poses. What were the criteria that were used to determine where a Cold War era Soviet visitor could and couldn’t go?

You can make some educated guesses. It’s not unreasonable to assume that major ports, coastlines, industrial areas and military and weapons areas were off limits. But that doesn’t cover the full scope of the open and closed areas.

Over at BoingBoing, there’s speculation that this was as much a tit-for-tat set of restrictions as it was a set of restrictions based on what the US Government didn’t want Soviets to see. As Cold War era historian Audra Wolfe, the author of the Slate article on this map, notes

The main premise is ‘strict reciprocity’. X% of Soviet coasts are off-limits, therefore X% of US coasts are off-limits, too.

Photo Credits: Rockefeller Archive Center, Item record: Rockefeller Family Archives (III) Record Group: 4 Nelson A. Rockefeller – Personal, Series: Washington D.C Files, Subseries: O.9 Special Assistant to the President Declassified Materials, 1954-1956, 1969 Box: 4 Folder 94.
Written and posted from the British Library, London (51.53004, -0.12765)

Another Piece Of Bloggage By Gary

Self professed ”geek with a life”, geo-blogger, geo-talker and geo-tweeter, Gary works in London and Berlin as Director of Global Community Programs for Nokia’s HERE Maps; he’s a co-founder of WhereCamp EU, the chair of w3gconf and sits on the W3C POI Working Group and the UK Location User Group. A contributor to the Mapstraction mapping API, Gary speaks and presents at a wide range of conferences and events including Where 2.0, State of the Map, AGI GeoCommunity, Geo-Loco, Social-Loco, GeoMob, the BCS GeoSpatial SG and LocBiz. Writing as regularly as possible on location, place, maps and other facets of geography, Gary blogs at www.vicchi.org and tweets as @vicchi.

Mail | Web | Twitter | Facebook | LinkedIn | Google+ | More Posts (362)

All Points Blog—Jack Levis, UPS, Keynotes Location Intelligence 2013

Jack Levis, is known to many readers as “the UPS guy” in the Penn State Public Broadcasting production The Geospatial Revolution. He gave the opening keynote at this year's Location Intelligence Conference in Washington, DC. He basically backed up his now-famous quip about how UPS used... Continue reading

All Points Blog—Esri’s Timely Severe Weather Map

Update: Moore, Oklahoma Tornado Public Information Map, too. Esri shares: Get the latest info on the ground as it happens. Esri’s live Severe Weather Map allows you to view continuously updated tornado reports, wind storm info, weather warnings, and precipitation. The map also... Continue reading

All Points Blog—GeoNews from Asia: Alibaba Gets into Mapping, the Man behind Esri in APAC

China's largest Internet company Alibaba has made a significant investment into AutoNavi, a key provider of mobile maps and directions. Alibaba is handing over $294 million for a 28% stake in AutoNavi Holdings, which boasts a 100 million-plus user base and  30% ownerhip of the mobile... Continue reading

All Points Blog—Where are the ACA Eligible in Illinois and other Health GIS News

Health & Disability Advocates has released an expanded interactive mapping tool that shows where uninsured Illinois residents live, highlighting who will be eligible to gain some form of coverage under the Affordable Care Act. It's an update of a map from last year with more data from... Continue reading

Directions Magazine—Google Geospatial Announcements from Google I/O 2013: Should GIS Users Care?

Google announced new location services APIs, a new Google Maps and a visual refresh for Google Maps at Google I/O last week. There was lots of descriptive coverage from the mainstream and tech press. But there was very little response from the geospatial community - except from Esri. Who should or should not be excited about the new Google Maps and APIs?

All Points Blog—Pitney Bowes Insights User Conference Skips 2013

Back in April Pitney Bowes Software announced via a message to customers that it would not be holding its Insights User Conference this year, but rather would use the year to revamp the organization. The event is usually held in May or June. The PB Software group includes the software... Continue reading

LiDAR News—Nuclear Underwater Laser Scanner

It was recently used successfully at Nine Mile Point 1, one of the oldest reactors in the United States, to inspect the steam dryer assembly and support brackets. Continue reading →

Click Title to Continue Reading...

OpenGeo—New Job Postings

hiringOpenGeo is looking for talented people to join our team. We offer interesting technical work, competitive salaries, great benefits, and a fantastic working environment. Most importantly we challenge our employees to build the best open source and interoperable tools for spatial data on the web. We added a few new posts this week, if any look like a fit for you, please apply!

Here’s a list of our open positions:

UX Developer -  We’re seeking a talented user experience developer to design and implement creative user interfaces for our innovative open source geospatial software.

Support Manager -  OpenGeo is looking for a support manager to ensure that customers large and small are familiarized with our software, properly trained in its function, and supported if anything should go wrong. The ability to think quickly and communicate clearly in a fast-paced environment is essential. Enthusiastic problem-solving skills and a desire to be engaged at all levels of a problem are even better.

Software Project Manager -  OpenGeo is seeking a skilled Software Project Manager to help us bring open source software to governments, commercial enterprises, NGOs, and other organizations around the world.

Java Developer - OpenGeo is seeking skilled software engineers interested in helping us bring open source software to organizations around the world. Our team improves the open source components underlying the OpenGeo Suite, allowing a wide variety of customers to share and edit data using open standards.

Front End Developer -  We’re looking for someone who is ready to work with peers in design and engineering to create pixel-perfect interfaces across a range of projects and products. You’ll own the code-base, work on the hard problems, build your ideas into reality, and help determine best practices throughout our organization.

Sales Account Manager – Our current (and future) clients are looking to open source to solve their spatial IT needs. Our account managers help commercial enterprises and federal clients use our innovative, open source geospatial software as efficiently and effectively as possible, allowing them to get more than ever out of their geospatial instances.

Here’s the full list, please apply and/or spread the word!

Spatial Law and Policy—5 Key Spatial Law and Policy Links (May 20, 2013)


Five links from the most recent Spatial Law and Policy Update prepared for the members of the Centre for Spatial Law and Policy. For more information about becoming a member of the Centre, click here.

ESA Study recommends free, open data policy for Sentinel data  (Geospatial World)


INTERNET LAW - Use of Mobile Phone Geolocation in Ireland's Criminal Proceedings  (ibls)  An informative discussion on the use of geolocation data from mobile devices by Irish authorities.



Judge Allows FBI To Use Evidence Collected Via Stingray Fake Cell Towers  (techdirt)  I find it interesting that it did not bother the judge that law enforcement failed to explain how the "Stingray" technology worked.


Germany cancels $1.3 billion purchase of unmanned Euro Hawk surveillance drones  (Washington Post) To quote from the article "A government official said Tuesday the decision not to buy four more drones was taken after it became clear that getting the required authorization to fly them over European airspace would be too costly." I wonder whether addressing privacy concerns were part of the anticipated costs. 

Crowdsourcing - a great concept but are you aware of the legal risks?  (Kingsley Napley) Written by a UK law firm - but issues are applicable in most countries.
 

Between the Poles—Reusing integrated geospatial and design data across the construction lifecyle

One of the most important things that impressed me at the Geospatial World Forum 2013 (GWF 2013) conference in Rotterdam is the degree to which in the Netherlands that building information modeling (BIM) and geospatial are perceived to be tightly linked.  In my previous post I gave an overview of a presentation by Bram Mommers, who works for the large private engineering company ARCADIS, on why integrating geospatial into the construction process is important.

CB-NL construction processJaap Bakkers, who is with the Rijkswaterstaat, the national water company in the Netherlands,  presented more details about the Concept Library (CB-NL) initiative. 

It is supported by the Dutch Council on Building Information (BIR), which is a joint industry and government council created to foster the development of building information modeling (BIM) in the Netherlands.  It includes government agencies such as Rijkswaterstaat, private construction contractors, and engineering and architural firms.  Government funds it, but most of its expertise is seconded from industry. 

Construction processes in the Netherlands

CB-NL GIS for planningIn the Netherlands many government projects are private-public partnerships (P3), where a private sector firm or consortium is responsible for the design-build-finance-maintain phases of the lifecycle and the government as the owner is responsible for operation.

CB-NL semantic structureMany AEC firms are adopting BIM because it is cheaper, reduces risk of budget, schedule overruns, and results in fewer change orders.  They may be motivated to adopt BIM to increase their margin or because they are required to by the owner, which is often a governmental organization such as the Rijkswaterstaat.  Once construction is complete, at commissioning, the owner is handed a large volume of facilities data and as-builts.  But this data is often unusable by the owner because it is incompatible or non-interoperable with the owner's asset management, GIS, and other systems.  This is the primary objective of the Concept Library (CB-NL), to create standards that enable re-use of design and construction data for operations.  This is one example of the CB-NL data impedancedata impedance problem, where at every handover, design to construction, construction to operations, data is lost and has to be recreated.

CB-NL GIS for asset managementGeospatial in the construction process

Marcel Reuvers, Manager of Geo-standards at Geonovum, gave an overview of some the critical roles that geospatial plays on the construction lifecycle.

  • Planning / preparation phase
  • Asset management / maintenance
  • Managing as-builts

I would add sustainable design which always requires geospatial information about local prevailing weather pattern and the location and orientation of neighbouring structures for right to light, wind, solar heating, natural lighting, solar PV generation potential, and other analysis.

I blogged previously about some fundamental changes to the construction process that will make geospatial central to the construction process.  What has been proposed is that a post-construction survey would become the critical source of reliable asset information in the form of a 3D intelligent model which would be maintained in a geospatially-enabled asset database.   When a new project is initiated,  80-90% of the necessary information would already available in the database making a complete resurvey, as is the current construction practice, unnecessary.  All that is required before design can begin is minimal due diligence to validate the as-builts.   The new process also implies that there is a reliable geospatially-enabled asset database that is maintained thoughout the operations and maintenance phase of the lifecycle.

Concept Library (CB-NL)

In the Netherlands there is already a standard decomposition for buildings called COINS.  The idea is to build on this to create a general approach for decomposing infrastructure as well as buildings and that it suffiiciently general to include geospatial. 

The Concept Library is intended to map different terminology across domains: design, engineering, architecture, construction, asset management, facilities manmagement,and geospatial.  For example, it interelates terms like arch bridge, rail bridge, spanning structure, viaduct, and crossing, each of which may be used by a different domain to refer to the same structure. The business benefit is that itCB-NL BIM and GEOSPATIAL would reduce the data impedance problem, where at every handover in the construction lifecycle, designer to contractor or contractor to owner, data is lost and has to be recreated.

The vision is that the Concept Library is an open database based on a standard ontology  that is searchable and has an open API  so that vendors such as Autodesk, Bentley or ESRI can develop interfaces to it for their products.  

CB=NL and geospatial

CB-NL GIS for as-built managementCB-NL was initially focused on BIM, but is being extended to include geospatial.  CB-NL enables designers, contractors, asset managers and GIS staff to share a common dataset.  It also makes it possible to automate the process of populating asset and facilities management application and GIS databases for the operations and maintenance phase of the lifecycle.

Concept Library (CB-NL)

CB-NL pilot organizationsA two year project to develop the Concept Library has just been initiated, in January 2013, which is supported by a large number of government and private organizations.   It is using the OWL ontology language, which has been endorsed by the W3C.  It uses tools and constructs from buildingSmart's Semantic Constructs for inputting and editing semantic content.   Real world pilots,  for example, a Rijkswaterstaat water services project and the Schipol, Amsterdam, Almere ring road project, will be used to demnstrate the practicality of the approach.

CB-NL relevant standardsAccording to Marcel Reuvers, there are a number of standards that relate to the CB-NL project from a number of standards bodies including the OGC, buildingSmart, ISO/TC211, and LandXML.  Jaap Bakker said that the project team has been in touch wth the Open Geospatial Consortium (OGC) in additon to the buildingSmart Alliance about the CB-NL project.

AnyGeo—Webinar – Rebuilding After Sandy: Surveying the Aftermath

Free Webinar! Rebuilding After Sandy: Surveying the Aftermath – Last October, the second-costliest hurricane in U.S. history put our mapping and forecasting systems to the test. As it turns out, the tragic truth is that the best means of determining … Continue reading →

Free and Open Source GIS Ramblings—TimeManager in QGIS 2.0

Today, I updated my QGIS Time Manager plugin to version 0.8. It now works with the QGIS 2.0 API and that means that we can take advantage of all the cool new features in our animations. The following quick example uses the “multiply” blend mode with the tweet sample data which is provided by default when you install the plugin:

(The video here is a little small. Watch it on Youtube to see the details.)


The Big Blue Thread—EPA Region 7′s GIS VIP

By Shawn Henderson

After several attempts at college, including the part-time approach, I decided in the mid 2000’s to start taking full-time classes and finish up my degree.  I knew that I wanted computers to be my major, because I love technology, but I also had a strong affinity for geo-sciences.  Not knowing much about geographic information systems (GIS) at the time, it seemed to be the perfect mix of geography, geology, and computers and therefore tailored specifically to my interests.  I thought GIS was just going to be about map making, but I had a lot to learn.  I was in the first pure GIS class that my alma mater, Park University offered.  At the time there was no dedicated computer lab, and the text book was less than helpful, but it was interesting.  I remember that in the computer lab on the main floor of the science buildingpark there were only five computers with ArcGIS licenses; we had to fight other students who were working on reports in MS Word to get access to the software we needed.  Park’s Professor David Fox did the best with what resources were at his disposal, and he made the class really interesting and enjoyable.  I developed a good relationship with Dave.  One afternoon I was frustrated and fed up with the turn-over of professors in the Computer Science program back then, so I asked him if he would be my unofficial advisor. He agreed.  From then on, we were good.

 

One afternoon I had enough of my computer programming class and decided to go for a stroll to clear my mind.  I had been working on a user interface class but, the buttons and layout were not lining up. I wanted to throw the computer across the room.  I walked over by the library and found an advertisement for an EPA summer intern program.  At this point I had applied for a dozen internships and I chuckled to myself that I had absolutely no chance, but I also figured that I had nothing to lose.  It just so happened that I had a certification in MS Access, and a group at EPA was looking for an intern to develop a tracking database in Access.  I applied, the stars aligned, and I was accepted for the internship.

 

I quickly finished the tracking database, and I was able to detail into the Region’s GIS group and onto our Aqua Team with fellow colleagues like Roberta Vogel-Leutung and Laura Webb.  I transitioned into the Student Career Employment Program and was offered a full time position with the Agency after I graduated.  Sometime after that, my supervisor and I were brainstorming about GIS and we wondered if we could leverage my knowledge of Park’s program (which requires an internship) to offer their students a more robust GIS experience at EPA.   I approached Dave Fox with the idea, and he thought it was a fantastic approach.   Thus was born our GIS VIP (VOLUNTARY INTERNSHIP with PARK).  From there our program has blossomed with more than 15 students working on EPA GIS projects.

 

Map completed by Park Intern

Map completed by Park Intern

The experience of working with these students has been amazing!  There has been a variety of unique personalities come through the door.  I have had students that were worried and timid at the beginning, but by the end they were confidant and ready to save the world with GIS.  I’ve also had students come through to find out how much database/computer work is involved and realize that the real world experience of GIS isn’t something they want to head towards as a career goal.  In the end, not all the projects end up like we planned, but the experience the students and EPA staff get from these projects is invaluable.  Students have had the opportunity to work with EPA staff which provides them with professional experience and contacts.  In return the Agency gets a fresh look on things with young enthusiastic students and volunteer assistance on projects of substance.

Besides our work with Park, the Agency has several other voluntary opportunities.  Currently EPA Region 7’s Office of Public Affairs, is seeking a volunteer intern to work on social media coordination who is motivated, hard-working, and interested in helping the EPA protect human health and the environment.   You can find out all the details here.  Additionally our Superfund program is seeking two volunteer interns to work on separate projects found here and here.  These are great opportunities to build skills and your resume.  Heck my old boss  Jeffery Robichaud, also a fellow blogger, did his own volunteer internship with EPA in Philadelphia 20 years ago.

Shawn Henderson is an Environmental Protection Specialist with the Environmental Assessment and Monitoring Branch of the Environmental Services Division. He is a part of the Aqua Team, and conducts water quality sampling around the Region’s four states.  He has a Computer Science degree from Park University and helped to develop the Region’s KCWaterBug app and kcwaters.org.

 

VerySpatial—Once again, XKCD nails it.

Today’s XKCD coincides with today’s podcast!

All Points Blog—Esri to Map Pittsburgh’s Steps

Lauri Dafner, a solutions engineer at Esri's Philadelphia regional office joined a group of residents to plan this year's Step Trek, fundraiser that tours the ciites steps. She's working with the South Side Slopes Neighborhood Association to create "story map," which the local paper... Continue reading

All Points Blog—Sensor Journalism: A New Frontier for Tech, Maps and Ethics

Sensor journalism changes data journalists usual practice of using existing data for stories to handing them control of data collection. But how to do that - both practically and ethically - is a challenge. Columbia University plans to explore these issues, Emily Bell, director of... Continue reading

All Points Blog—Man’s Mental Map of Hometown Brings him Back to Family after 23 Years

Luo Gang  was on his way to kindergarten at age five when he was kidnapped and taken away to a new home more than 1000 miles away. Twenty three years later he leanred of a charity working to reunite such children with their parents. But how might he know about his home town? He... Continue reading

Directions Magazine—More than Mapping: Using GIS for disaster management

The devastation of Hurricane Sandy and the western wildfires in 2012 are sobering reminders that utilities always need to be prepared to respond to large-scale natural disasters. When faced with incidents of that size, a utility is forced to look at all of its resources in preparation, including those it doesn&rsquo;t typically utilize under normal conditions. Danny Petrecca, director of Product Management Enterprise GIS at Schneider Electric, explains how a typical implementation for an enterprise-wide GIS system can be used to better prepare utilities for disasters.

VerySpatial—A VerySpatial Podcast – Episode 409

A VerySpatial Podcast
Shownotes – Episode 409
May 19, 2013

Main Topic: Some thoughts on geofencing

  • Click to directly download MP3
  • Click to directly download AAC

    • Click for the detailed shownotes

    Music

  • This week’s podsafe music: “A Laptop Like You” by Jonathan Coulton




    • News

  • Construction company in Belize destroys Mayan pyramid
  • Lots of updates for Google Maps from Google I/O and Location APIs
  • ArcGIS for Windows Phone update, Windows Phone jumps to #3 in the smartphone market
  • ArcGIS API for Javascript 3.5



    • Web Corner

  • Geoguessr



    • Main topic

  • This week, we feature a conversation offering some of our thoughts on geofencing.



    • Tip of the week

  • URISA’s Vanguard Cabinet creates Outreach Committee



    • Events Corner

  • GIS in Public Health: 17-20 June, Miami, FL
  • GIS-Pro 2013: 16-19 Sept, Providence, RI
  • GIS in Transit: 16-17 Oct, Washington, DC
  • Locating the Future: 3-6 November, St Louis, MO



    • This week, A VerySpatial Podcast is sponsored by Esri

  • The new release of ArcGIS for AutoCAD is available to download at no cost. This update includes support for AutoCAD 2013 and faster loading of ArcGIS Online server connections.
    To learn more and to download, visit esri.com/autocad.

    • GeoServer Blog—GeoServer 2.3.2 released

    The GeoServer team is pleased to announce the release of GeoServer 2.3.2 for download.

    • This release includes and is made in conjunction with GeoTools 9.2.
    • The INSPIRE plugin has now graduated to extension and is included in this release. This plugin adds WMS and WFS capabilities support for metadata required for compliance with the European INSPIRE directive.
    • The application schema support (app-schema) support plugin now enables joining by default for data sources that support it.
    • Fixed transformation problems with projections based on Hotine Oblique Mercator (variant B) (for example Swiss CH1903 / LV03)
    • Fixed WFS lockups when a WFS 1.1 GetFeature is providing a schema referring back to the same server DescribeFeatureType
    • A new option to limit the file browser to the data directory, geared towards high security/multi-tenant environments

    More details can be found in the GeoServer 2.3.2 Release Notes.

    GeoSprocket Community Jive—Taking Tilemill 2 for a Spin


    When I took my first GIS class, I was told that 5% of my time would be spent making maps, while 90% of it would be spent corralling data into usable format and 5% would be spent beating an unresponsive plotter with a cardboard tube. This balance has definitely changed as interoperability has gone from prayer to practice, but I've continued to be frustrated by the time I feel gets lost to a missing shapefile extension or a falsely-defined projection.

    For all the fun afforded us by Mapbox's original Tilemill map design platform, it's always been sort of a GIS-y hassle to wrangle data into it. Mind you this is slight, glancing criticism - it's NOTHING compared to getting your geodata to work in Illustrator or any actual GIS platform. But I always found myself wishing I could spend less time racking my brain for where I put that awesome building footprint layer, or trying in vain to find the right ORDER BY syntax for a PostGIS datasource.

    Perhaps you've heard, but Mapbox sort of solved my whiny problems. Tilemill 2 is in unsupported alpha, but it's already fulfilling my dream of data-agnostic cartography. The basic idea is that the world - as derived from OpenStreetmap - is some pretty centralizable basedata, so why not just tap the source and style it however you like? Instead of pulling extracts or copies or subsets, Tilemill 2 just gives you the whole damn world, all 330GB-and-counting of it, via super-fast vector tiles (great explanation here). You get to style those tiles with the CartoCSS language, and at that point they're ready for your audience.

    It is A LOT of fun to have the world at your fingertips:




    For the moment there's no export or serving option, and it'll be interesting to see what Mapbox does with this tool in its already-robust custom mapping lineup. It's also worth noting that planet.osm is not ALL TEH DATAZ - we'll always need a way to use local or personal geodata. But this is a great leap for an already-impressive platform.

    It's liberating to be able to focus on cartography with the building blocks already in place.


    Props to Gretchen Peterson for some great color ideas as I fiddle with this.



    Ecostudies—Rounding of floating numbers in GRASS GIS r.mapcalc

    The GRASS GIS development team keeps on introducing new features and enhancements to GRASS 7.0. One of the latest examples is the enhancement of the round() function in r.mapcalc. Previously this function would always returns an integer, regardless of its … Continue reading →

    Andrew Zolnai Blog—A tale of two cities: web maps new and old

    Last I posted on vector online GIS, and that appears to be gaining traction. Mapbox offers through TileMill and OpenStreetMaps editing. These are new an emerging technologies that are exciting, and it contrasts with Esri who offers a slew of tools on the desktop and in arcgis.com. WMS is for example still immature on giscloud.com (though it is OGC compliant now), as are the symbology and labels. They do not offer model builder like Esri or Qgis (thru Sextante). But they do offer a service to process GIS functions online and allow to load data direct from web source, avoiding costly down- & up-loads. Here I compare how I used a 180K vector dataset from NOAA NGDC described previously.
      


    This is very much a work in progress, stay tuned for Arcgis Online for example. Also Google Fusion Tables I used elsewhere are not appropriate in this context. And of course there are many many more platforms bird-dogged for example by the blog roll below to the right. Here is, however, what GSHHG maps looks like in giscloud.com and ArcGIS for Home Use that offer modest barriers to entry:
    1. giscloud.com online
    2. screenshot in ArcGIS desktop
    3. rendered as WMS in arcgis.com


    GIS Lounge—Open and Machine Readable Now the Default for Government Data

    On May 9, 2013, President Barack Obama sign an executive order making the default for government data "open and machine readable". The executive order was accompanied by the White House's Open Data Policy.

    The post Open and Machine Readable Now the Default for Government Data appeared first on GIS Lounge.

    Between the Poles—Integrating geospatial into construction: the challenge

    I spent most of last week at the Geospatial World Forum 2013 (GWF 2013) in Rotterdam, which was an amazing event, because of its focus on monetizing geospatial value in vertical industries,  Industries for which there were symposia at GWF 2013 include construction and infrastructure, electic power and gas, mining and exploration, water as a resource, water distribution management, and agriculture in addition to more traditional sectors such as land management, photogrammetry and the environment.

    I spent most of my time in Construction and Infrastructure sessions.  There were many absolutely fascinating pesentation on the applicaton of geospatial technology in this sector.  Among the most far-reaching in terms of potential impacts were three or four talks that explicitly addressed the challenge of finding a practical way to integrate geospatial into construction processes.

    Value of geospatial information

    To put this in context, there is a strong drive in the Netherlands to integrate geospatial information into govenrment organizations.  Geonovum is leading the charge in this area.   By way of motivation there is a very interesting cost-benefit analysis in the context of the European INSPIRE initiaive by Ecorys and Grontmij in November 2009.  The scope of study was the cost and benefits of the collection, maintenance and dissimilation of geographic information, but just within governmental organizations in the Netherlands.  The study did not attempt to estimate the value of geospatial information to society as a whole.  It concluded that over 15 years, the total net benefit to government organizations in the Netherlands would be € 34 million (Ralf Duinmeijer, Joulz ICT private communication).

    Cost of poor interoperability

    To put this in the context of interoperability and what poor interoperability costs the economy and individual firms, in 2004 in a remarkable study the U.S. National Institute of Standards and Technology (NIST) attempted to identify and estimate the efficiency losses in the U.S. capital facilities industry resulting from inadequate interoperability.  The NIST study focussed on interoperability problems attributed to the highly fragmented nature of the industry, the industry’s continued paperbased business practices, a lack of standardization, and inconsistent technology adoption among stakeholders.  It concluded that inadequate interoperability cost the U.S. capital facilities industry $15.8 billion in annually in 2002, but qualified the conclusion by saying that this is likely a conservative figure because there were additional significant inefficiency and lost opportunity costs associated with interoperability problems that were beyond the scope of NIST analysis.

    At GWF 2013 it was reported that Rijkswaterstaat, responsible for public works and water management as part of the Dutch Ministry of Infrastructure, has estimated that poor interoperability costs it € 800 million per year.

    Barriers to integrating BIM and geospatial

    Bram Mommers, who is with ARCADIS Netherlands, set the stage by looking at what the barriers are that are hindering the integration of geospatial into the constrcution process.  (ARCADIS is a large international company that provides consultancy, design, engineering and management services in the fields of infrastructure, water, environment and buildings.)

    ARCADIS BIM and GeospatialTraditionally the challenge has been that civil engineering on one hand and geospatial on the other have been different cultures.  The way Carl Steinitz put is that they work at different scales.  Geospatial scientists deal with the universal, engineers with the very specific. 

    Bram gave some examples of these parallel worlds. Geospatial folks make maps, engineers and architects make drawings.  Engineers and architects use CAD or BIM design tools.  Geospatial folks use GIS.  The geospatial standard for buildings and infrastructure is CityGML.  The AEC standard for BIM models is Industry Foundation Classes (IFC).

    ARCADIS BIM and Geospatial HOV NijmegenARCADIS has been involved in projects that integrated geospatial into the desing process.  On the HOV Nijmegen project it was found that integrating geospatial and engineering design in a single database resulted in a single copy of each data element and multiple use.  It simplified communication and increased the quality of the final design.  It also enabled automated analysis of the consequences of design choices with the result that the planning cycle was shorter.   Bram mentioned several other projects that benefitted from the integration of geospatial with the construction process.

    Based on their experience with these projects, Bram and his colleagues concluded that there are three main barriers to the integration of civll engineering and geospatial.

    • Semantics - for example, different terms used for the me things by geospatial analysts and civil engineers and designers
    • Different topology - examples,  (1) geospatial uses point, lines, and polygons; CAD/BIM uses splines, nurbs, and other parametric curves and treats polygons in a different way from geospatial topology; (2) features with location vs objects with location as an attribute
    • Data formats - for example, geospatial data is stored in shape files, GML, anARCADIS Civil engineering and geospatiald CityCML; CAD/BIM uses DWG, DGN, RVT files, and IFC

    Mapping semantics

    To address the first issue of semantics, a Dutch initiative called Concept Library (CB-NL) sponsored by the Dutch Council on Building Information (BIR), a joint government and industry initiative, has been created with the objective of developed an open, on-line system to map between the terminologies used in different domains.  The goal is a single integrated model for construction (buildings and infrastructure) that would allow design, construction, maintenance and operations to share the same data.  The concept library would be extended to include geospatial.  The overall goal as Bram stated it is

    • Ontology for the build environment - multiple sets of domain terminologies mapped on to it
    • One language
    • Combines geospatial and construction

    ARCADIS BIM and GIS OrganizationsThe impacts of this appproach that Bram sees are

    • Store once, use multiple times - avoid redundant data
    • Integrated information management - based on data custodians
    • Geolocation as a property of an object - in additon to features

    Bram listed a number of organizations in the private construction sector that are supporting this initiative.

    LiDAR News—LiDAR Pulse Densities

    The folks at Watershed Sciences have created an outstanding white paper entitled, "LiDAR Pulse Densities Comparison". Continue reading →

    Click Title to Continue Reading...

    LiDAR News—Google Glass Review – Wink, Wink

    The Saturday Night Live folks tested Google Glass. Here is there review. Continue reading →

    Click Title to Continue Reading...

    Steve's Little World—On invasives and knee jerk reactions

    Just a little thought piece on some environmental news happening here in the Bay Area. So on the Nerd for Nature group that I am a part of, someone posted this article with the subject “wtf” http://www.californiaprogressreport.com/site/fema-plans-clear-cutting-85000-berkeley-and-oakland-trees Besides that title being so incredibly alarmist, it is articles like this that give environmentalists a bad name. […]

    LiDAR News—Situational Awareness RFI at the Tactical Level

    To help address these challenges, DARPA has issued a Request for Information (RFI) about technologies that can help lead to digitization of dismounted squads. Continue reading →

    Click Title to Continue Reading...

    mousebird consulting—GeoData Display for Mobile Devices with OpenGL ES


    I gave a talk last night at the San Francisco Bay Area GeoMeetup.  This one was timed to coincide with Google I/O.

    The talks were the 5 minute Ignite format and, just to be different, I went deep technical.  I pulled a couple algorithms out of WhirlyGlobe-Maply and explained them.  I like how it turned out.



    The video has audio and, hey, it's short.

    The slides, sans video, can be found here.

    Bing Maps Blog—Test Post

    Test

    Fuzzy Tolerance—Priceless

    The Map Guy(de)—MapGuide tidibts: The resource dependency chain

    You probably know in MapGuide that there is a whole different bunch of type of resources available at your disposal, when authoring up your data, maps and applications.

    You probably also know that if you move, rename or delete a resource you may be affecting and/or breaking other resources that depend on it.

    How about the big picture? Well here's one I've prepared earlier.

    As you can see, with the exception of the Load Procedure, Application Definition and Web Layout, every other resource type has a dependency on another resource type.

    Consider what you may be potentially breaking when you move, rename or delete a given resource.

    Spatialists—Chinese names of European countries

    A while ago I proposed etymologic cartography as a field of study. Somewhat related, I found this map that doesn’t show the etymology of placenames but literal translations of country names into English from Chinese:

    Note: I have no way of checking the correctness of the place names in this map (and some do sound a bit ungrammatical), so take them with a pinch of salt.

    Source: mapsontheweb.tumblr.com

    gisn8—Microsoft vs. Esri

    So this morning I've received another notice from Esri about another Windows update that can screw up Arc. Didn't we just have something like this about a month ago? And this on the heels of news on the break between ArcGIS Online and Bing. Coincidence or slap fight?

    P.S. Bing coming to AutoCAD 2014.

    Cameron Shorter—Open Letter to OGC re Geoservices REST API

    Taxonomy upgrade extras: 
    OSGeo
    ogc

    This page aims to collate community concerns related to the adoption of the "Geoservices REST API" document as a standard of the Open Geospatial Consortium (OGC). The page has been collaboratively edited, and delivered by the board of the OSGeo Foundation (OSGeo) to the OGC and OGC voting members on Friday 17 May 2013.

    The original document can be found here: http://wiki.osgeo.org/wiki/Geoservices_REST_API

    Cover Letter from the OSGeo Board

    The board of the Open Source Geospatial Foundation (OSGeo) is presenting this letter to the OGC. The letter highlights concerns about the "GeoServices REST API" from many people within the OSGeo community. As always, if there is anything the OSGeo board can do to help, then please let us know.

    Signed: Jeff McKenna (OSGeo president), Peter Batty, Jáchym Cepický, Michael Gerlek, Anne Ghisla, Mark Lucas, Daniel Morissette, Cameron Shorter, Frank Warmerdam

    Open Letter to OGC and voting members

    May 2013

    We, the undersigned, have concerns that approving the "Geoservices REST API" as an OGC standard, will have detrimental impacts on interoperability within the spatial industry.

    We strongly urge that the proposed "Geoservices REST API", as it stands in May 2013, be rejected as an OGC standard.

    People have listed different reasons for concern. These concerns are described below.

    Signed

    1. Cameron Shorter, Geospatial Solutions Director at LISAsoft, core contributor & coordinator of OSGeo-Live, OSGeo Board member
    2. Mark Lucas, Founding member and board of directors for OSGeo foundation, Principal Scientist for RadiantBlue Technologies Inc.
    3. Stephen Woodbridge, Director of iMaptools.com, Contributor and/or PSC of Mapserver, pgRouting, PAGC, and PostGIS
    4. Even Rouault, Geospatial developer, OSGeo Charter Member, core contributor and PSC member of GDAL/OGR, contributor of Mapserver, PROJ.4, libgeotiff, shapelib, libtiff
    5. Gerhard Triebnig, Managing Director at EOX IT Services GmbH
    6. Brent Wood, Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
    7. Stephan Meissl, CTO at EOX IT Services GmbH, contributor to Mapserver, PSC chair of EOxServer
    8. Jeroen Ticheler, Director of GeoCat, project founder and PSC chair of GeoNetwork opensource
    9. Just van den Broecke, Director at Just Objects, contributor to Heron Mapping Client, secretary of OSGeo Dutch Local Chapter, member at OpenGeoGroep
    10. Milo van der Linden, member at OpenGeoGroep
    11. Landon Blake, GIS Department Manager/Land Surveyor at KSN, OSGeo California Chapter Board Representative.
    12. Daniel Morissette, President at Mapgears, OSGeo Board member, core contributor and PSC member of Mapserver and GDAL/OGR. Former OGC TC member and involved in the implementation of several OGC WxS specs in MapServer.
    13. Bob Basques, GIS Systems Developer at the City of Saint Paul, MN. Public Works GIS (GISmo), Technical Director at SharedGeo, OSGeo Charter Member, OSGeo TCMUG local chapter member, Co-founder and PSC member of GeoMoose project.
    14. Pedro-Juan Ferrer Matoses, PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
    15. Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
    16. María Arias de Reyna, software engineer at GeoCat, Spain, member of OSGeo Spanish Local Chapter.
    17. Anne Ghisla, OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
    18. Micho Garcia, Freelance and member of geomati.co, Spain, member of Spanish Local Chapter
    19. Margherita Di Leo, OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
    20. Jorge Sanz, GIS Consultant at Prodevelop, OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
    21. Pablo Sanxiao, CTO and co-founder at iCarto, OSGeo Spanish Local Chapter Member, Spain
    22. Frank Steggink, GIS software developer at Vicrea, The Netherlands, member of the Dutch Local Chapter
    23. Olivier Courtin, Oslandia co-founder, core contributor or/and PSC member of Mapserver and PostGIS. OGC TC member.
    24. Wladimir Szczerban, OSGeo Spanish Local Chapter Member, Spain
    25. Anita Graser, GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
    26. Volker Mische, geospatial software engineer, creator of GeoCouch
    27. Iván Sánchez, OSGeo Spanish Local Chapter Member, head of OpenStreetMap Spain, OpenStreetMap Foundation member, Humanitarian OpenStreetMap Team member, Spanish SDI working group member
    28. Gabriel Carrión, Strategy Manager at gvSIG association
    29. Sandro Santilli, OSGeo Charter Member, PostGIS and GEOS PSC member and core hacker.
    30. Javier Diaz, member of Geoinquietos Bs As [1], member of the Organizing Committee FOSS4G Bs As 2013 [2]
    31. Jo Cook, Consultant at Astun Technology, former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of FOSS4G 2013
    32. Francisco José Peñarrubia, CTO and co-founder at SCOLAB. Members of gvSIG Association
    33. Shanmugam Ganeshkumar, Director of GeoICON, member OSGeo Malaysia Chapter
    34. Barry Rowlingson, Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
    35. Stefan Keller, University of Applied Sciences, Rapperswil (Switzerland), Member of Swiss OSM (SOSM) and QGIS association and of organizing committees of pgConf.DE and FOSSGIS 2013, and member of eCH (e-government standards of Switzerland)
    36. Andrew Bailey, OSGeo member, Astun Technology
    37. Suchith Anand, OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
    38. Carlos Krefft, GIS software developer at CSTARS - University of Miami, OGC and OSGeo Member.
    39. Stefano Costa, OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
    40. Peter Baumann, Jacobs University, OGC member, WCS.SWG chair, editor of 10+ specs (disclaimer: this is an expression of my personal opinion and not in any way endorsed by OGC)
    41. Peter Batty, CTO of Geospatial Division at Ubisense, OSGeo board member, former CTO of Intergraph and GE Smallworld, Technical Committee member of OGC in its formative years c 1995-97
    42. Barend Köbben, OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at ITC-University of Twente
    43. Paolo Cavallini, Faunalia, OSGeo member, GFOSS.it member and former president, QGIS-PSC
    44. FRans Thamura, Indonesia, OSGeo Indonesia, organizer]
    45. Sanghee Shin, Founder and CEO of Gaia3D, OSGeo Charter Member, Representative of OSGeo Korean Chapter, Chairman of Open Source GIS Alliance Korea
    46. Benni Purwonegoro,Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
    47. Jachym Cepicky, Czech Republic, member of OSGeo Board of Directors
    48. Pat Cappelaere, Vightel Corporation
    49. Jürgen Fischer, norBIT GmbH, QGIS core developer
    50. Maria Antonia Brovelli, OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at Politecnico di Milano, Italy
    51. Nacho Varela, GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
    52. Vasile Craciunescu, OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
    53. Abbas Abdul Wahab, Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
    54. Roy Braam, Software Engineer @ | B3Partners
    55. Peteris Bruns, Latvia, GIS Consultant & Software Engineer @ | SunGIS
    56. Giovanni Manghi, Portugal, Faunalia, OSGeo member, OSGeo-Portugal
    57. Hugo Martins, UK, Lutra Consulting, WebGIS Developer, OSGeo-Portugal Member
    58. Saber Razmjooei, UK, Lutra Consulting, Co-Founder
    59. Peter Wells, UK, Lutra Consulting, Co-Founder
    60. Sidney Gijzen, The Netherlands, Researcher GIS @ Alterra, Wageningen UR
    61. Miles Fidelman, US, Principal, Protocol Technologies Group, LLC
    62. Puneet Kishor, OSGeo Charter Member; Geology, Univ. of Wisconsin-Madison; Creative Commons
    63. António José Silva, Portugal, GIS Consultant, OSGeo-Portugal Member
    64. AndreMano, Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
    65. Mauricio Miranda, Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
    66. Paulo Machado, Portugal, Software Engineer @ PT Inovação
    67. Alvaro Anguix, Spain, General Manager at gvSIG Association
    68. Santiago Higuera, CEO at Mercatorlab, OSGeo Spanish Local Chapter Board Member, Spain
    69. Alan Boudreault, Developer at Mapgears, contributor to Mapserver and GDAL/OGR.
    70. Mike Saunt, UK, Owner at Astun Technology Ltd, OSGeo sponsor
    71. Michael Smith, OSGeo Charter Member, Physical Scientist US Army Corps of Engineers Remote Sensing GIS Center
    72. Angelos Tzotsos, OSGeo Charter Member, Researcher at National Technical University of Athens
    73. Michaël Douchin, France, GIS consultant & software engineer at 3liz
    74. Pedro Venâncio, Portugal, GIS Analyst @ Municipality of Pinhel
    75. Jorge Gustavo Rocha, Portugal, GIS Professor at Universidade do Minho
    76. Daniel Kastl, Japan, Georepublic, Founder
    77. John Callahan, US, Research Scientist and GIS/Remote Sensing Specialist, University of Delaware
    78. Kalyan Janakiraman, Senior Systems Analyst, Business Development Services, NSW Land and Property Information, Sydney, Australia
    79. Phillip Davis, Director, National Geospatial Technology Center of Excellence, Texas, USA
    80. Simon Pigot, contributor to and PSC member of GeoNetwork opensource (speaking for myself, not an official view of my employer)
    81. John Bryant, Consultant, Mammoth Mapping, Dawson City, Canada and GIS/DB Admin, Jupiter Mines, Perth, Australia
    82. Christos Iossifides, Remote Sensing Instructor, Laboratory Teaching Staff, Remote Sensing Instructor and Researcher, National Technical University of Athens
    83. Tim Bowden, Spatial Consultant, Perth, Australia
    84. Luca Delucchi, GIS Technician, Trento, Italy
    85. Bart van den Eijnden, GIS software developer, Utrecht, Netherlands
    86. Henry Addo, Software Developer at Ushahidi [3], contributor of OSGeo-Live
    87. Stefano Iacovella, GIS consultant & software engineer, Rome, Italy
    88. Meine Toonen, Software Engineer @ B3Partners, The Netherlands
    89. Arne Kepp, Software Engineer, Oslo, Norway
    90. Pirmin Kalberer, Managing director Sourcepole, FOSSGIS member, Contributor of GDAL/OGR, QGIS, Mapfish, UbuntuGIS, OSGeo-Live, Switzerland
    91. Dr. Horst Düster, Managing director Sourcepole, FOSSGIS member, Treasurer QGIS Project QGIS, Zürich, Switzerland
    92. Richard Duivenvoorde, Managing director & software developer Webmapper, QGIS community member
    93. Steven Feldman, Principal at KnowWhere Consulting and Chair of the LOC for FOSS4G 2013
    94. Edward Mac Gillavry, Managing director & software developer Webmapper
    95. Maxim Dubinin, CEO at NextGIS, head of GIS-Lab.info
    96. Fran Boon, PMC Chair at Sahana Foundation, CTO of AidIQ
    97. Ian Edwards, Chair OSGeo:UK
    98. Dmitriy Baryshnikov Developer at NextGIS, GDAL/OGR committer, wxGIS developer, GIS-Lab.info community member
    99. Chris van Lith, Director B3Partners, member of OpenGeoGroep
    100. Vincent Picavet, co-founder of Oslandia, founding member and treasurer of OSGeo-FR
    101. Stefan A. Tzeggai, creator of AtlasStyler SLD editor, founder of empirica systeme gmbh
    102. Roald de Wit, Geospatial Software Engineer, Melbourne, Australia
    103. Manuel Grizonnet, working at the French Space Agency, ORFEO ToolBox library developer
    104. Toru Mori, President & CEO, Orkney, Inc., Yokohama, Japan, Representative of OSGeo Japan Chapter, OSGeo Charter Member
    105. Markus Schneider, TMC chair of the deegree project, CEO of Occam Labs
    106. Elena Mezzini, Remote Sensing and GIS Technician, GFOSS.it member, Bologna, Italy
    107. Alexander Bruy, NextGIS, QGIS core developer
    108. Danilo Furtado, Portugal, OSGeo member, OSGeo-Portugal
    109. Andreas Schmitz, Germany, deegree core developer and TMC member, CTO of Occam Labs
    110. Oliver Tonnhofer, Germany, MapProxy core developer, founder & CTO of Omniscale
    111. Thomas Baschetti, Germany, Freelancer, Mapbender PSC Member, FOSSGIS member
    112. Ian Mayo, GeoSpatial developer, UK
    113. Ivan Mincik, CEO of GISTA s.r.o., Slovakia
    114. Edmar Moretti, Software developer, i3GEO core developer, Brazil
    115. Diego Moreira, GIS Analyst, Contributor of QGIS, Brazil
    116. Luigi Pirelli, Freelance Analyst/Programmer, co-founder of Italian OSGEO Local Chapter GFOSS.it, Italy
    117. Kyle Shannon Software Developer, contributor of GDAL/OGR, United States
    118. David Mateos, worker member at Terrativa S. Coop. and OSGeo Spanish Local Chapter Member, Spain
    119. Luis Franco, researcher and GIS analyst at the University of Santiago de Compostela, Spain
    120. Gabriel Roldan, Software Developer, Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Member
    121. Dimitris Kotzinos, OSGEO Charter Member, OSGEO Greek Chapter founder, Assistant Professor TEI of Serres, Greece
    122. Stefan Steiniger, owner of GEO Steiniger Ltda., contributor to OpenJUMP GIS and OpenTripPlanner and author of several FOSS4G overview articles, Canada/Chile
    123. Nobusuke Iwasaki, Senior Researcher, National Institute for Agro-Environmental Sciences, Tsukuba, Japan, OSGeo Japan Chapter Board Member
    124. Ross Johnson, Land Information Officer, City of Ryde Council and NSW Committee member of Surveying & Spatial Sciences Institute (SSSI)
    125. Kumaran Narayanaswamy, CEO & Managing Director of kCube Consultancy Services Pvt Ltd India.[4], Member of India OSGeo Chapter.
    126. Luis Fernando Bueno, Professor at Federal University of Rondonia, researcher and GIS analyst, Brazil.
    127. Bob Bruce, FEC, P.Eng., Geomatics Engineer, Winnipeg, Manitoba, Canada.
    128. Moritz Lennert, Researcher in geography at the Free University of Brussels (ULB), GRASS-PSC
    129. Ian Turton, Software developer and open standards advocate, GeoTools-PSC
    130. Gérald Fenoy, OSGeo Charter member, Founder and CEO of GeoLabs SARL, France
    131. David Bitner, OSGeo Charter member, OSGeo VP for Geodata, OSGeo Twin Cities Chapter, Sahana Software Foundation Board of Directors, MetroGIS Coordinating Committee Chair, ownerdbSpatial
    132. Peter Löwe, OSGeo Charter member, Senior Researcher at Deutsches GeoForschungsZentrum GFZ, General Manager GISIX.com
    133. Gavin Fleming, OSGeo Charter member, owner of AfriSpatial.
    134. Frank Maes, GeoICT professional, Head Operations at Geosparc, Contributor & community member of Geomajas, OSGeo member

    Summary

    The OGC candidate standard titled "GeoServices REST API" is currently, in May 2013, being considered to be approved as an Open Geospatial Consortium (OGC) standard. The vote to accept the document as a standard is unusually contentious. The controversy is the cause of this open letter.

    The candidate standard was previously released for public comment and can be found on the request for public comment page (though public comment has been closed for now).

    The candidate standard attempts to standardize a suite of web services such as a service which provides map images, a service which provides geospatial feature data, and a service which performs geospatial processing. The candidate standard focuses on interactions via a defined hierarchy of URLs and using predominantly a particular set of JSON schemas for the exchange of geospatial data.

    Criticism and Response

    The criticism of the adoption of this particular document as an OGC Standard includes a wide variety of reasons such as:

    • the OGC's process through which the document was developed which is thought to lack sufficient flexibility to respond to input from various stakeholders,
    • the focus of the document on 'REST' and 'API' which is seen as not matching the ideas others have for these concepts,
    • the names of the standard and of the services which are seen as potentially confusing,
    • the functionality of the new services which are considered to duplicate that of existing services already standardized by the OGC such as WMS, WFS, WCS, and WPS,
    • the addition of a new set of services based on new URL patterns and new JSON exchange formats which is seen as duplicating the efforts of other working groups bringing similar ideas to the updates of existing OGC services,
    • the re-introduction in the new services of previously resolved interoperability issues which is seen as failing to build on the existing knowledge and experience,
    • the use of the particular JSON schemas which are seen as having little industry acceptance and are incompatible with other widely used schemas, and
    • the lack of implementation diversity which is thought to give the vendor of the one complete implementation an unusual commercial advantage on top of the vendor's already dominant position in the domain.

    These issues have potential impacts on the use of 'Open Standards' by governments and companies, on the interoperability of software interacting with standards compliant OGC services, on the costs to developers and users of standards compliant software, on the understanding of 'Open Standards' by the public at large, and, possibly, on the reputation of the OGC as a champion of interoperability.

    In particular there are concerns by some that adoption of the standard will likely result in a combination of the following:

    1. The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
    2. Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
    3. Sponsors (such as governments) who require compliance with OGC standards will discover that applications don't communicate together, due to applications supporting different OGC standards that essentially do the same thing.
    4. This will result in a diminished importance of OGC, as the "OGC standards" stamp of approval will not equate interoperability.
    5. After a while, in order to solve interoperability issues, a respected international organisation or program will likely take the initiative to mandate one standard as the preferred standard for all agencies to follow. To date, the OGC has provided this leadership.
    6. One standard taking prominence over the other will likely lead to the other being neglected or deprecated, resulting in many OGC compliant systems becoming legacy systems in the process. This should be considered an undesirable outcome for a standards organisation.

    In response to these issues, the authors of the Geoservices REST API document have stated that:

    • the process of the OGC has been followed completely,
    • the specification actually is RESTful and does define an API,
    • the name, due to the controversy, is open for modification
    • the OGC does not forbid duplication of service functionality, already has duplication between the W*S and the S*S (sensor) family of standards, should not block progress in the name of 'one true way', and harmonization between the services can be considered in the future,
    • the JSON format exists and functions, and
    • there are alternative implementations for some of these services.

    The authors also stress that the existence of a large user base shows the service is useful, and that the standardization of the services at the OGC may encourage new implementations.

    The SWG has published two documents in response to various comments.

    Positions on the vote

    The discussion raises a number of issues, many based upon complex technical concepts and implications. This makes it difficult for voting OGC members considering whether to support (or not) the "Geoservices REST API" as a standard. The following provides one analysis of the positions on the vote, aimed to simplify and summarize key points. However, it does not necessarily represent the opinions held by all signatories above.

    The pros for accepting the "Geoservices REST API" document as an OGC standard
    • The OGC should be in the business of developing good standards, not in choosing which standards should be implemented.
    • The proposers of the document want to make a standard and have followed all the rules of the OGC. The work of any such group of members deserves serious, good faith consideration.
    • The need for an integrated suite of services using simple data, which is addressed (partially) by the document, is real. The proposed document is pushing the OGC on this issue.
    • The proposed document could be useful to a number of people.
    • The proposed document is not significantly more broken than the existing standards of the OGC. As one author of standards notes:
    "I know how totally impossible it is to write a good standard, so the weaknesses in the existing document seem more acceptable."
    The cons
    • The OGC actually is, whether it should be or not, in the position of recommending interoperable standards for geospatial services. The proposed document is not good enough, has implementations dominated by one vendor's server implementation, and not publicly supported enough, to be considered at the same level as existing standards.
    • Adopting a standard implies a desire to maintain the standard, but OGC's desire to support this approach has been questioned by some. In particular, the lack of collaboration and willingness to accept recommendations from the community on this version of the "Geoservices REST API" document bodes ill for the future.
    • The overlap in functionality between the proposed services and the existing services, notably with the ongoing work to modularize the existing services, is almost 100 percent. However, compatibility is low.
    • There is already a published document: http://www.esri.com/library/whitepapers/pdfs/geoservices-rest-spec.pdf so there is no need for the document to be adopted as an OGC Standard merely for interoperability with the ESRI implementation.
    • The document, as a new, separate effort, repeats mistakes which were made and since solved by the other services.
    • The document focuses on the past (notably with backwards compatibility and use of only GET/POST) not on the future.
    • The document needs a comprehensive editorial review and substantial rewriting for clarity.
    A conclusion

    Both simple answers are bad.

    A simple acceptance of the standard would introduce a new set of 'OGC approved' open services. The OGC approval might enable governments to buy a XXXX-new-name-here-XXXX solution instead of a W*S or a S*S solution. The path forwards towards harmonizing the services is unclear. Fixing this document in addition to fixing the W*S services will be a pain.

    Simply rejecting the solution would be bad for the OGC. It would place the OGC in the position of picking winners and losers in the standards business. It would mean that the OGC is stuck on the project of fixing the W*S standards to meet some nebulous future functionality without having any path to get there. It would discourage innovation and progress.

    Is there any third way?

    Well, actually, there is a different way of thinking of the issue. Overall, there appears to be a shared desire for an integrated suite of geospatial services, originally focused on a simple data model, built on the exchange of well defined resources in simple formats including JSON, accessible and usable using the core HTTP verbs, and discoverable through following HTML links and patterns of URL paths. The hope is that such a suite can be designed based on the best expertise of the OGC, can be widely supported by the community, and can be implemented and tested by multiple groups. Neither the proposed document, nor the current services meet this vision. So the work, ultimately, is on improving all the services at the OGC, first to modularize them, then to enable simple implementations, and finally to link those implementations into a functional suite. Since this is the work that is already happening, perhaps the vote is an unfortunate distraction and the productive way forward is merely to redouble the efforts to create the next versions of the standards.

    Issues with the document

    Beyond the controversy described above, there are issues with the Geoservices REST API document itself. Even if the standard deserves support, these issues could be considered blockers to the adoption of the current, May 2013, document.

    The critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort and is beyond the scope and intent of this Open Letter.

    The critique can be found at: http://wiki.osgeo.org/wiki/Geoservices_REST_API_critique.

    Note that some of these critiques hold the document to OGC's current, standards writing guidelines. The OGC has been striving to develop better standards so new standards must meet higher requirements than past standards. The lack of clarity in the proposed document is not substantially worse than many published standards but ought to be resolved in new standards.

    Further Concerns

    Technical Concerns

    • see this discussion for detailed arguments why OGC WCS is superior to the "GeoServices REST API" Part 6. It concludes:

    In summary, the ESRI "Geoservice REST API" Imaging part is at a technological level where WCS departed from some 5 years ago.Inconciseness of the specification at large will make it difficult for third parties to come up with interoperable implementations. The components making up the ESRI "Geoservice REST API" provide natural blocks assignable to the matching SWGs. As for Part 6 of the ESRI "Geoservice REST API", if to become a standard it needs to be discussed in the WCS.SWG for harmonization, clarification, and improvement.

    Methodological Concerns

    • The Geoservices REST API can not be amended (other than editorial changes in the specification document), because of a requirement for backward compatibility with the ESRI implementation. This has limited improvements in this version of the candidate specification.

    Further Reading

    Please add links to referenced documents, related news stories or blog posts here.

    LISasoft Blog—Open Letter to OGC re Geoservices REST API

    Taxonomy upgrade extras: 
    OSGeo
    ogc

    This page aims to collate community concerns related to the adoption of the "Geoservices REST API" document as a standard of the Open Geospatial Consortium (OGC). The page has been collaboratively edited, and delivered by the board of the OSGeo Foundation (OSGeo) to the OGC and OGC voting members on Friday 17 May 2013.

    The original document can be found here: http://wiki.osgeo.org/wiki/Geoservices_REST_API

    Cover Letter from the OSGeo Board

    The board of the Open Source Geospatial Foundation (OSGeo) is presenting this letter to the OGC. The letter highlights concerns about the "GeoServices REST API" from many people within the OSGeo community. As always, if there is anything the OSGeo board can do to help, then please let us know.

    Signed: Jeff McKenna (OSGeo president), Peter Batty, Jáchym Cepický, Michael Gerlek, Anne Ghisla, Mark Lucas, Daniel Morissette, Cameron Shorter, Frank Warmerdam

    Open Letter to OGC and voting members

    May 2013

    We, the undersigned, have concerns that approving the "Geoservices REST API" as an OGC standard, will have detrimental impacts on interoperability within the spatial industry.

    We strongly urge that the proposed "Geoservices REST API", as it stands in May 2013, be rejected as an OGC standard.

    People have listed different reasons for concern. These concerns are described below.

    Signed

    1. Cameron Shorter, Geospatial Solutions Director at LISAsoft, core contributor & coordinator of OSGeo-Live, OSGeo Board member
    2. Mark Lucas, Founding member and board of directors for OSGeo foundation, Principal Scientist for RadiantBlue Technologies Inc.
    3. Stephen Woodbridge, Director of iMaptools.com, Contributor and/or PSC of Mapserver, pgRouting, PAGC, and PostGIS
    4. Even Rouault, Geospatial developer, OSGeo Charter Member, core contributor and PSC member of GDAL/OGR, contributor of Mapserver, PROJ.4, libgeotiff, shapelib, libtiff
    5. Gerhard Triebnig, Managing Director at EOX IT Services GmbH
    6. Brent Wood, Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
    7. Stephan Meissl, CTO at EOX IT Services GmbH, contributor to Mapserver, PSC chair of EOxServer
    8. Jeroen Ticheler, Director of GeoCat, project founder and PSC chair of GeoNetwork opensource
    9. Just van den Broecke, Director at Just Objects, contributor to Heron Mapping Client, secretary of OSGeo Dutch Local Chapter, member at OpenGeoGroep
    10. Milo van der Linden, member at OpenGeoGroep
    11. Landon Blake, GIS Department Manager/Land Surveyor at KSN, OSGeo California Chapter Board Representative.
    12. Daniel Morissette, President at Mapgears, OSGeo Board member, core contributor and PSC member of Mapserver and GDAL/OGR. Former OGC TC member and involved in the implementation of several OGC WxS specs in MapServer.
    13. Bob Basques, GIS Systems Developer at the City of Saint Paul, MN. Public Works GIS (GISmo), Technical Director at SharedGeo, OSGeo Charter Member, OSGeo TCMUG local chapter member, Co-founder and PSC member of GeoMoose project.
    14. Pedro-Juan Ferrer Matoses, PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
    15. Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
    16. María Arias de Reyna, software engineer at GeoCat, Spain, member of OSGeo Spanish Local Chapter.
    17. Anne Ghisla, OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
    18. Micho Garcia, Freelance and member of geomati.co, Spain, member of Spanish Local Chapter
    19. Margherita Di Leo, OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
    20. Jorge Sanz, GIS Consultant at Prodevelop, OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
    21. Pablo Sanxiao, CTO and co-founder at iCarto, OSGeo Spanish Local Chapter Member, Spain
    22. Frank Steggink, GIS software developer at Vicrea, The Netherlands, member of the Dutch Local Chapter
    23. Olivier Courtin, Oslandia co-founder, core contributor or/and PSC member of Mapserver and PostGIS. OGC TC member.
    24. Wladimir Szczerban, OSGeo Spanish Local Chapter Member, Spain
    25. Anita Graser, GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
    26. Volker Mische, geospatial software engineer, creator of GeoCouch
    27. Iván Sánchez, OSGeo Spanish Local Chapter Member, head of OpenStreetMap Spain, OpenStreetMap Foundation member, Humanitarian OpenStreetMap Team member, Spanish SDI working group member
    28. Gabriel Carrión, Strategy Manager at gvSIG association
    29. Sandro Santilli, OSGeo Charter Member, PostGIS and GEOS PSC member and core hacker.
    30. Javier Diaz, member of Geoinquietos Bs As [1], member of the Organizing Committee FOSS4G Bs As 2013 [2]
    31. Jo Cook, Consultant at Astun Technology, former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of FOSS4G 2013
    32. Francisco José Peñarrubia, CTO and co-founder at SCOLAB. Members of gvSIG Association
    33. Shanmugam Ganeshkumar, Director of GeoICON, member OSGeo Malaysia Chapter
    34. Barry Rowlingson, Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
    35. Stefan Keller, University of Applied Sciences, Rapperswil (Switzerland), Member of Swiss OSM (SOSM) and QGIS association and of organizing committees of pgConf.DE and FOSSGIS 2013, and member of eCH (e-government standards of Switzerland)
    36. Andrew Bailey, OSGeo member, Astun Technology
    37. Suchith Anand, OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
    38. Carlos Krefft, GIS software developer at CSTARS - University of Miami, OGC and OSGeo Member.
    39. Stefano Costa, OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
    40. Peter Baumann, Jacobs University, OGC member, WCS.SWG chair, editor of 10+ specs (disclaimer: this is an expression of my personal opinion and not in any way endorsed by OGC)
    41. Peter Batty, CTO of Geospatial Division at Ubisense, OSGeo board member, former CTO of Intergraph and GE Smallworld, Technical Committee member of OGC in its formative years c 1995-97
    42. Barend Köbben, OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at ITC-University of Twente
    43. Paolo Cavallini, Faunalia, OSGeo member, GFOSS.it member and former president, QGIS-PSC
    44. FRans Thamura, Indonesia, OSGeo Indonesia, organizer]
    45. Sanghee Shin, Founder and CEO of Gaia3D, OSGeo Charter Member, Representative of OSGeo Korean Chapter, Chairman of Open Source GIS Alliance Korea
    46. Benni Purwonegoro,Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
    47. Jachym Cepicky, Czech Republic, member of OSGeo Board of Directors
    48. Pat Cappelaere, Vightel Corporation
    49. Jürgen Fischer, norBIT GmbH, QGIS core developer
    50. Maria Antonia Brovelli, OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at Politecnico di Milano, Italy
    51. Nacho Varela, GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
    52. Vasile Craciunescu, OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
    53. Abbas Abdul Wahab, Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
    54. Roy Braam, Software Engineer @ | B3Partners
    55. Peteris Bruns, Latvia, GIS Consultant & Software Engineer @ | SunGIS
    56. Giovanni Manghi, Portugal, Faunalia, OSGeo member, OSGeo-Portugal
    57. Hugo Martins, UK, Lutra Consulting, WebGIS Developer, OSGeo-Portugal Member
    58. Saber Razmjooei, UK, Lutra Consulting, Co-Founder
    59. Peter Wells, UK, Lutra Consulting, Co-Founder
    60. Sidney Gijzen, The Netherlands, Researcher GIS @ Alterra, Wageningen UR
    61. Miles Fidelman, US, Principal, Protocol Technologies Group, LLC
    62. Puneet Kishor, OSGeo Charter Member; Geology, Univ. of Wisconsin-Madison; Creative Commons
    63. António José Silva, Portugal, GIS Consultant, OSGeo-Portugal Member
    64. AndreMano, Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
    65. Mauricio Miranda, Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
    66. Paulo Machado, Portugal, Software Engineer @ PT Inovação
    67. Alvaro Anguix, Spain, General Manager at gvSIG Association
    68. Santiago Higuera, CEO at Mercatorlab, OSGeo Spanish Local Chapter Board Member, Spain
    69. Alan Boudreault, Developer at Mapgears, contributor to Mapserver and GDAL/OGR.
    70. Mike Saunt, UK, Owner at Astun Technology Ltd, OSGeo sponsor
    71. Michael Smith, OSGeo Charter Member, Physical Scientist US Army Corps of Engineers Remote Sensing GIS Center
    72. Angelos Tzotsos, OSGeo Charter Member, Researcher at National Technical University of Athens
    73. Michaël Douchin, France, GIS consultant & software engineer at 3liz
    74. Pedro Venâncio, Portugal, GIS Analyst @ Municipality of Pinhel
    75. Jorge Gustavo Rocha, Portugal, GIS Professor at Universidade do Minho
    76. Daniel Kastl, Japan, Georepublic, Founder
    77. John Callahan, US, Research Scientist and GIS/Remote Sensing Specialist, University of Delaware
    78. Kalyan Janakiraman, Senior Systems Analyst, Business Development Services, NSW Land and Property Information, Sydney, Australia
    79. Phillip Davis, Director, National Geospatial Technology Center of Excellence, Texas, USA
    80. Simon Pigot, contributor to and PSC member of GeoNetwork opensource (speaking for myself, not an official view of my employer)
    81. John Bryant, Consultant, Mammoth Mapping, Dawson City, Canada and GIS/DB Admin, Jupiter Mines, Perth, Australia
    82. Christos Iossifides, Remote Sensing Instructor, Laboratory Teaching Staff, Remote Sensing Instructor and Researcher, National Technical University of Athens
    83. Tim Bowden, Spatial Consultant, Perth, Australia
    84. Luca Delucchi, GIS Technician, Trento, Italy
    85. Bart van den Eijnden, GIS software developer, Utrecht, Netherlands
    86. Henry Addo, Software Developer at Ushahidi [3], contributor of OSGeo-Live
    87. Stefano Iacovella, GIS consultant & software engineer, Rome, Italy
    88. Meine Toonen, Software Engineer @ B3Partners, The Netherlands
    89. Arne Kepp, Software Engineer, Oslo, Norway
    90. Pirmin Kalberer, Managing director Sourcepole, FOSSGIS member, Contributor of GDAL/OGR, QGIS, Mapfish, UbuntuGIS, OSGeo-Live, Switzerland
    91. Dr. Horst Düster, Managing director Sourcepole, FOSSGIS member, Treasurer QGIS Project QGIS, Zürich, Switzerland
    92. Richard Duivenvoorde, Managing director & software developer Webmapper, QGIS community member
    93. Steven Feldman, Principal at KnowWhere Consulting and Chair of the LOC for FOSS4G 2013
    94. Edward Mac Gillavry, Managing director & software developer Webmapper
    95. Maxim Dubinin, CEO at NextGIS, head of GIS-Lab.info
    96. Fran Boon, PMC Chair at Sahana Foundation, CTO of AidIQ
    97. Ian Edwards, Chair OSGeo:UK
    98. Dmitriy Baryshnikov Developer at NextGIS, GDAL/OGR committer, wxGIS developer, GIS-Lab.info community member
    99. Chris van Lith, Director B3Partners, member of OpenGeoGroep
    100. Vincent Picavet, co-founder of Oslandia, founding member and treasurer of OSGeo-FR
    101. Stefan A. Tzeggai, creator of AtlasStyler SLD editor, founder of empirica systeme gmbh
    102. Roald de Wit, Geospatial Software Engineer, Melbourne, Australia
    103. Manuel Grizonnet, working at the French Space Agency, ORFEO ToolBox library developer
    104. Toru Mori, President & CEO, Orkney, Inc., Yokohama, Japan, Representative of OSGeo Japan Chapter, OSGeo Charter Member
    105. Markus Schneider, TMC chair of the deegree project, CEO of Occam Labs
    106. Elena Mezzini, Remote Sensing and GIS Technician, GFOSS.it member, Bologna, Italy
    107. Alexander Bruy, NextGIS, QGIS core developer
    108. Danilo Furtado, Portugal, OSGeo member, OSGeo-Portugal
    109. Andreas Schmitz, Germany, deegree core developer and TMC member, CTO of Occam Labs
    110. Oliver Tonnhofer, Germany, MapProxy core developer, founder & CTO of Omniscale
    111. Thomas Baschetti, Germany, Freelancer, Mapbender PSC Member, FOSSGIS member
    112. Ian Mayo, GeoSpatial developer, UK
    113. Ivan Mincik, CEO of GISTA s.r.o., Slovakia
    114. Edmar Moretti, Software developer, i3GEO core developer, Brazil
    115. Diego Moreira, GIS Analyst, Contributor of QGIS, Brazil
    116. Luigi Pirelli, Freelance Analyst/Programmer, co-founder of Italian OSGEO Local Chapter GFOSS.it, Italy
    117. Kyle Shannon Software Developer, contributor of GDAL/OGR, United States
    118. David Mateos, worker member at Terrativa S. Coop. and OSGeo Spanish Local Chapter Member, Spain
    119. Luis Franco, researcher and GIS analyst at the University of Santiago de Compostela, Spain
    120. Gabriel Roldan, Software Developer, Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Member
    121. Dimitris Kotzinos, OSGEO Charter Member, OSGEO Greek Chapter founder, Assistant Professor TEI of Serres, Greece
    122. Stefan Steiniger, owner of GEO Steiniger Ltda., contributor to OpenJUMP GIS and OpenTripPlanner and author of several FOSS4G overview articles, Canada/Chile
    123. Nobusuke Iwasaki, Senior Researcher, National Institute for Agro-Environmental Sciences, Tsukuba, Japan, OSGeo Japan Chapter Board Member
    124. Ross Johnson, Land Information Officer, City of Ryde Council and NSW Committee member of Surveying & Spatial Sciences Institute (SSSI)
    125. Kumaran Narayanaswamy, CEO & Managing Director of kCube Consultancy Services Pvt Ltd India.[4], Member of India OSGeo Chapter.
    126. Luis Fernando Bueno, Professor at Federal University of Rondonia, researcher and GIS analyst, Brazil.
    127. Bob Bruce, FEC, P.Eng., Geomatics Engineer, Winnipeg, Manitoba, Canada.
    128. Moritz Lennert, Researcher in geography at the Free University of Brussels (ULB), GRASS-PSC
    129. Ian Turton, Software developer and open standards advocate, GeoTools-PSC
    130. Gérald Fenoy, OSGeo Charter member, Founder and CEO of GeoLabs SARL, France
    131. David Bitner, OSGeo Charter member, OSGeo VP for Geodata, OSGeo Twin Cities Chapter, Sahana Software Foundation Board of Directors, MetroGIS Coordinating Committee Chair, ownerdbSpatial
    132. Peter Löwe, OSGeo Charter member, Senior Researcher at Deutsches GeoForschungsZentrum GFZ, General Manager GISIX.com
    133. Gavin Fleming, OSGeo Charter member, owner of AfriSpatial.
    134. Frank Maes, GeoICT professional, Head Operations at Geosparc, Contributor & community member of Geomajas, OSGeo member

    Summary

    The OGC candidate standard titled "GeoServices REST API" is currently, in May 2013, being considered to be approved as an Open Geospatial Consortium (OGC) standard. The vote to accept the document as a standard is unusually contentious. The controversy is the cause of this open letter.

    The candidate standard was previously released for public comment and can be found on the request for public comment page (though public comment has been closed for now).

    The candidate standard attempts to standardize a suite of web services such as a service which provides map images, a service which provides geospatial feature data, and a service which performs geospatial processing. The candidate standard focuses on interactions via a defined hierarchy of URLs and using predominantly a particular set of JSON schemas for the exchange of geospatial data.

    Criticism and Response

    The criticism of the adoption of this particular document as an OGC Standard includes a wide variety of reasons such as:

    • the OGC's process through which the document was developed which is thought to lack sufficient flexibility to respond to input from various stakeholders,
    • the focus of the document on 'REST' and 'API' which is seen as not matching the ideas others have for these concepts,
    • the names of the standard and of the services which are seen as potentially confusing,
    • the functionality of the new services which are considered to duplicate that of existing services already standardized by the OGC such as WMS, WFS, WCS, and WPS,
    • the addition of a new set of services based on new URL patterns and new JSON exchange formats which is seen as duplicating the efforts of other working groups bringing similar ideas to the updates of existing OGC services,
    • the re-introduction in the new services of previously resolved interoperability issues which is seen as failing to build on the existing knowledge and experience,
    • the use of the particular JSON schemas which are seen as having little industry acceptance and are incompatible with other widely used schemas, and
    • the lack of implementation diversity which is thought to give the vendor of the one complete implementation an unusual commercial advantage on top of the vendor's already dominant position in the domain.

    These issues have potential impacts on the use of 'Open Standards' by governments and companies, on the interoperability of software interacting with standards compliant OGC services, on the costs to developers and users of standards compliant software, on the understanding of 'Open Standards' by the public at large, and, possibly, on the reputation of the OGC as a champion of interoperability.

    In particular there are concerns by some that adoption of the standard will likely result in a combination of the following:

    1. The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
    2. Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
    3. Sponsors (such as governments) who require compliance with OGC standards will discover that applications don't communicate together, due to applications supporting different OGC standards that essentially do the same thing.
    4. This will result in a diminished importance of OGC, as the "OGC standards" stamp of approval will not equate interoperability.
    5. After a while, in order to solve interoperability issues, a respected international organisation or program will likely take the initiative to mandate one standard as the preferred standard for all agencies to follow. To date, the OGC has provided this leadership.
    6. One standard taking prominence over the other will likely lead to the other being neglected or deprecated, resulting in many OGC compliant systems becoming legacy systems in the process. This should be considered an undesirable outcome for a standards organisation.

    In response to these issues, the authors of the Geoservices REST API document have stated that:

    • the process of the OGC has been followed completely,
    • the specification actually is RESTful and does define an API,
    • the name, due to the controversy, is open for modification
    • the OGC does not forbid duplication of service functionality, already has duplication between the W*S and the S*S (sensor) family of standards, should not block progress in the name of 'one true way', and harmonization between the services can be considered in the future,
    • the JSON format exists and functions, and
    • there are alternative implementations for some of these services.

    The authors also stress that the existence of a large user base shows the service is useful, and that the standardization of the services at the OGC may encourage new implementations.

    The SWG has published two documents in response to various comments.

    Positions on the vote

    The discussion raises a number of issues, many based upon complex technical concepts and implications. This makes it difficult for voting OGC members considering whether to support (or not) the "Geoservices REST API" as a standard. The following provides one analysis of the positions on the vote, aimed to simplify and summarize key points. However, it does not necessarily represent the opinions held by all signatories above.

    The pros for accepting the "Geoservices REST API" document as an OGC standard
    • The OGC should be in the business of developing good standards, not in choosing which standards should be implemented.
    • The proposers of the document want to make a standard and have followed all the rules of the OGC. The work of any such group of members deserves serious, good faith consideration.
    • The need for an integrated suite of services using simple data, which is addressed (partially) by the document, is real. The proposed document is pushing the OGC on this issue.
    • The proposed document could be useful to a number of people.
    • The proposed document is not significantly more broken than the existing standards of the OGC. As one author of standards notes:
    "I know how totally impossible it is to write a good standard, so the weaknesses in the existing document seem more acceptable."
    The cons
    • The OGC actually is, whether it should be or not, in the position of recommending interoperable standards for geospatial services. The proposed document is not good enough, has implementations dominated by one vendor's server implementation, and not publicly supported enough, to be considered at the same level as existing standards.
    • Adopting a standard implies a desire to maintain the standard, but OGC's desire to support this approach has been questioned by some. In particular, the lack of collaboration and willingness to accept recommendations from the community on this version of the "Geoservices REST API" document bodes ill for the future.
    • The overlap in functionality between the proposed services and the existing services, notably with the ongoing work to modularize the existing services, is almost 100 percent. However, compatibility is low.
    • There is already a published document: http://www.esri.com/library/whitepapers/pdfs/geoservices-rest-spec.pdf so there is no need for the document to be adopted as an OGC Standard merely for interoperability with the ESRI implementation.
    • The document, as a new, separate effort, repeats mistakes which were made and since solved by the other services.
    • The document focuses on the past (notably with backwards compatibility and use of only GET/POST) not on the future.
    • The document needs a comprehensive editorial review and substantial rewriting for clarity.
    A conclusion

    Both simple answers are bad.

    A simple acceptance of the standard would introduce a new set of 'OGC approved' open services. The OGC approval might enable governments to buy a XXXX-new-name-here-XXXX solution instead of a W*S or a S*S solution. The path forwards towards harmonizing the services is unclear. Fixing this document in addition to fixing the W*S services will be a pain.

    Simply rejecting the solution would be bad for the OGC. It would place the OGC in the position of picking winners and losers in the standards business. It would mean that the OGC is stuck on the project of fixing the W*S standards to meet some nebulous future functionality without having any path to get there. It would discourage innovation and progress.

    Is there any third way?

    Well, actually, there is a different way of thinking of the issue. Overall, there appears to be a shared desire for an integrated suite of geospatial services, originally focused on a simple data model, built on the exchange of well defined resources in simple formats including JSON, accessible and usable using the core HTTP verbs, and discoverable through following HTML links and patterns of URL paths. The hope is that such a suite can be designed based on the best expertise of the OGC, can be widely supported by the community, and can be implemented and tested by multiple groups. Neither the proposed document, nor the current services meet this vision. So the work, ultimately, is on improving all the services at the OGC, first to modularize them, then to enable simple implementations, and finally to link those implementations into a functional suite. Since this is the work that is already happening, perhaps the vote is an unfortunate distraction and the productive way forward is merely to redouble the efforts to create the next versions of the standards.

    Issues with the document

    Beyond the controversy described above, there are issues with the Geoservices REST API document itself. Even if the standard deserves support, these issues could be considered blockers to the adoption of the current, May 2013, document.

    The critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort and is beyond the scope and intent of this Open Letter.

    The critique can be found at: http://wiki.osgeo.org/wiki/Geoservices_REST_API_critique.

    Note that some of these critiques hold the document to OGC's current, standards writing guidelines. The OGC has been striving to develop better standards so new standards must meet higher requirements than past standards. The lack of clarity in the proposed document is not substantially worse than many published standards but ought to be resolved in new standards.

    Further Concerns

    Technical Concerns

    • see this discussion for detailed arguments why OGC WCS is superior to the "GeoServices REST API" Part 6. It concludes:

    In summary, the ESRI "Geoservice REST API" Imaging part is at a technological level where WCS departed from some 5 years ago.Inconciseness of the specification at large will make it difficult for third parties to come up with interoperable implementations. The components making up the ESRI "Geoservice REST API" provide natural blocks assignable to the matching SWGs. As for Part 6 of the ESRI "Geoservice REST API", if to become a standard it needs to be discussed in the WCS.SWG for harmonization, clarification, and improvement.

    Methodological Concerns

    • The Geoservices REST API can not be amended (other than editorial changes in the specification document), because of a requirement for backward compatibility with the ESRI implementation. This has limited improvements in this version of the candidate specification.

    Further Reading

    Please add links to referenced documents, related news stories or blog posts here.

    Markus Neteler—FOSS4G-CEE 2013: Program published!

    Join us at FOSS4G Central and Eastern Europe (FOSS4G-CEE) 2013 from 16th - 20th June, National Library of Romania, Bucharest, Romania.


    You will meet well known Keynote Speakers (random order): Jeff McKenna, Paul C. Smits, Jáchym Čepický, Schuyler Erle, Maria Antonia Brovelli, Dirk Frigne, Markus Neteler, Alyssa Wright, and Radu Puchiu.

    Check the long list of Practical Workshops and Oral Presentations at: http://2013.foss4g-cee.org/program/schedule
    Check out for the additional Code Sprint, the Open GeoData Hackathon, and the Open Data Side Event.

    How to arrive? See http://2013.foss4g-cee.org/venue/map

    LiDAR News—Hardware Compression of LiDAR Data

    Hardware compression is considerably faster than software compression, while it also alleviates the processor load. Continue reading →

    Click Title to Continue Reading...

    AnyGeo—First Look – Exploring The New Google Maps

    To my surprise the new Google maps is available already. Upon receipt of the email providing me with a special link I immediately launched maps from Chrome for a quick, first look. The first thing I noticed was the browser … Continue reading →

    GIS Lounge—Google Map Redesign

    Googles Maps is preparing to debut its newly revamped Google Maps.  Terming it “smart recommendations” the new functionality of Google Maps is intended to be more interactive and custom tailored to the specific user.  The more you use the map to search for locations, favorite items by starring them, and write location reviews, the more [...]

    The post Google Map Redesign appeared first on GIS Lounge.

    My Corner of the Web—Running Unicorn as a Service on Debian Linux

    Reblogged from Robert Reiz:

    Unicorn is a very fast app server for Ruby on Rails. You just have to go to the APP_ROOT and type in "unicorn_rails". And your app is running.

    The problem with that is, if your server reboots your app is down. And you have to start it again by hand. That is not so cool!

    Wouldn't it be cool if you could start your Ruby on Rails like that:

    Read more… 213 more words

    This article saved my life. Set up Unicorn to start on server reboot.

    All Points Blog—GEOINT with SAP HANA, Esri ArcGIS

    David Cruickshank from SAP's Co-Innovation Lab (COIL) describes in his blog the architecture of how SAP users can perform geospatial intelligence (GEOINT) analysis using both SAP's HANA in-memory database with a workflow to Esri's ArcGIS. Some of the workflow is explained as... Continue reading

    Sean Gillies Blog—Getting back into OpenStreetMap

    The new OSM editor is a pleasure to use and I've been inspired to fix up my neighborhood a bit. It was cool to see these historic homes (designated Fort Collins landmarks, in fact) pop up in MapBox just minutes after I submitted them.

    http://a.tiles.mapbox.com/v3/sgillies.map-jtvmlgox/-105.09175479412079,40.56621496147184,18/640x480.png

    Google Maps, on the other hand, has no historic homes and a rather outdated and (sadly) never to be realized development proposal in the neighborhood. Fixing Google's map for free is not high on my list of priorities.

    Next, I'd like to finally get some Pleiades-related data into the OpenHistoricalMap sandbox.

    AnyGeo—GeoTech Webinars and Professional Development

    Another roundup of webinars of interest being delivered to your desktop in the near future… these are an awesome way to test drive a solution, hear directly from industry experts, and experience a little professional development. The following webinars of … Continue reading →

    VerySpatial—The Apostrophe’s Last Stand

    The Wall Street Journal has an interesting, spatially relevant article on regulation and standardization of place names and the disappearing apostrophe in U.S. signage, “Theres a Question Mark Hanging Over the Apostrophes Future: Its Practically Against the Law to Use the Mark in a Places Name; Sorry, Pikes Peak.”    Read the title again to catch the humor that Barry Newman uses to construct a brief history of place signage.

    He states that the U.S. is the only country that standardized out apostrophes because they were seen as conveying private ownership of a public place. The USGS Board on Geographic Names set up in 1890 by President Harrison has eradicated around 250,000 apostrophes from federal maps. In contrast, the Apostrophe Protection Society kept the Mid Devon council in England from banning the use of apostrophes in street signs.  According to an in-depth article on the loss of the apostrophe and the history of Fell’s Point or Fells Point, Maryland, “What’s the Point?” from the Underbelly: From the Deepest Corners of the Maryland Historical Society Library, only five natural features have official license to use the possessive apostrophe in 2013.

    The quoted arguments for the apostrophe is that it is part of proper English language usage, that it connotes information about the history of a place, and that not using them can cause confusion and miscommunication. What is most interesting about the WSJ article is who isn’t quoted – cartographers. How do cartographers feel about the vanishing apostrophe in place names?

     

    All Points Blog—Landsat Data Continuity Mission: The Long Swath by NASA Earth Observatory-GigaPan

    On April 12, 2013, the Landsat Data Continuity Mission (LDCM) reached its final orbit, 705 kilometers (438 miles) above Earth. One week later, the satellite's natural-color imager scanned a swath of land 185-kilometers wide and 9,000 kilometers long (120 by 6,000 miles)--an unusual,... Continue reading

    My Georamblings...—GeoNYC

    Many thanks to the folks that put on GeoNYC Tuesday night. I did a presentation on the balloon mapping projects we have been doing in part to set up Public Labs community here in Philadelphia.

    Footnotes