martenhogeweg

Strange Connections

2011-04-24T13:39:00.000-07:00

This past week was one of strange connections, when GI Science, friends and family, business and society all seemed intertwined...

It started off with AGILE, no, not this one, but the 14th edition of the get-together of the Association Geographic Information Laboratories Europe. This lead to some confusion, but perhaps we got some of the AGILE (the big one) to appreciate GIS a little bit...

We spoke about mixing and matching open source with closed source work with various samples shown coming from 52North, Research Studios Austria, and ourselves with respect to sensor observation, web processing, contributing to OpenStreetMap, and information discovery.

With the growing amount of information, the desire to filter out what's not relevant is growing as well. What I found one of the best paper presentations at the AGILE conference (the small one), was about Modeling Umwelten following the ideas of German scientist Jakob von Uexküll.

Jakob was no uilskuiken, no matter how similar the two terms may sound...

Jakob's theory states that an organism creates and reshapes its own Umwelt when it interacts with the world, creating a so-called 'functional circle'. This reminded by of Social Circles by @padday.

Filtering information becomes critical in disaster response situations. Some of the presentations at AGILE spoke of semantic filtering of information feeds using the context (dare I say Umwelt?) of the event and its participants. Surprisingly I found my self discussing emergency response using Eagle with my old colleagues at Esri NL.

During the week I crossed more of my Social Circles: meeting an old friend, spending time with Esri NL, and spending a day with my brother and our cousin-several-times-removed at DeLimes.

At DeLimes, we played urban golf with BuurtLab, studied how farms are managed differently, and what makes a local store survive, by actual visits and listening to the people themselves, following the 7S Framework.

When did you last ask a user how what they got actually was what they needed (will a new laptop really help you land a job?).

And so ended a week of interactions with different groups, discussions of software delivery models, management approaches, and catching up with family and friends. New links were established, old links where renewed and strengthened.

For those who haven't noticed yet: http://sourceforge.net/projects/geoportal/

2011-01-03T15:35:00.000-08:00

Ah, thanks to Bill Thorp for reminding me to finish the trilogy...

Yes, Geoportal Server has been available on SourceForge since late October. Licensing, source code, proper credit to 3rd party components, etc are all in place. We migrated most of the Geoportal Extension documentation from the Esri Resource Center to the new Geoportal Server wiki.

Just before Xmas, we added the OpenLS connector for ArcGIS Server to the project! This is an update of an old connector that was available for ArcIMS several years ago. Configure it with ArcGIS Server services and provide an interface following the OGC specification of Open Location Service Implementation Standard. We're running a test instance that uses some ArcGIS Online services.

So now we're getting our plans together for 2011. Looking at:

Complete wiki documentation
GeoSPARQL interface
Enhanced metadata editor
Sitemap synchronizer
WMTS client (JS API, Flex, Silverlight)
0-configuration database support
Enhance OpenID/Oauth use
ebRIM, Feature Data Dictionary, Feature Catalog support
Upgrades to new underlying API (JS, Flex, Silverlight)

Some of these are just ongoing maintenance, ideas we've had for a while, or things already in the works (like the enhanced metadata editing). Others (like the GeoSPARQL interface) will take a while to develop and fully use. I'll put a brief description of these items on the feature list and would be curious to your responses or other features you would want to see in the Geoportal Server.

Are we there yet?

2010-09-28T20:57:00.000-07:00

Is anybody home?
It's been three weeks since we announced that the Esri Geoportal extension would be released as open source. It may have seemed a bit quiet since, but rest assured, a lot has happened.

In my previous post I indicated we were looking at a Creative Commons-esk license model. Several people pointed out that this license is not recommended for source code. And yes we did see the FAQ on that topic.

And so started a quest for an appropriate license model that would give everyone: developers, implementers, and (sorry folks!) Esri what they need. If there only was a geek channel on TV. this would have made a great 'America's next top (license) model' show.

Along the way we revisited a great resource collected by the state of Massachusetts IT Division. It’s a bit dated, but the basics still apply.

While Esri has experience with open source from a licensing-in perspective, with the Geoportal extension going open source, we're flipping into a new role for the first time of licensing-out Esri software under an open source license.

From the 50+ (!) models discussed in that spreadsheet, it would have been great fun to use the Motosoto or Sleepycat license models, just because of their names. But no, we didn't select either.

Geoportal Extension will be released under the Apache 2.0 license!

Are we there yet?

Almost. We now have the task of moving source code, documentation, and such to a public source repository and find a proper way to integrate/link with the Esri websites (resource centers and such). But with this big step made, we're getting close.

Geoportal Extension to Become Open Source

2010-09-07T23:00:00.000-07:00

Despite code documentation and samples as included on the Geoportal Resource Center, implementers of the Geoportal Extension have continued asking for source code access to support integration with content management systems, map viewers, desktop etc.

Esri listened to these requests and I am happy to be able to announce that:

the Geoportal Extension will enter a next phase in its evolution and become a Free and Open Source solution from Esri.

Seven years ago we created what was then called the GIS Portal Toolkit as a software and services solution, based on code from a number of earlier projects and prototypes for data discovery and map viewing.

Since starting with GIS Portal Toolkit, those using it to create geoportals and clearinghouses have had access to its source code. Understandably, as people looked at creating websites that reflected the organization's identity.

At version 9.3 this resulted in Geoportal becoming a fully supported extension with a full maintenance program. We put a lot of effort in making Geoportal Extension configurable to a large extent with respect to authentication, metadata profile support, the index used for discovery, localization, skin development, and more.

The Geoportal Extension will be released under one of the variants of the Creative Commons open source license and will include elements like:

Geoportal Web application
OGC CSW 2.0.2 catalog service with OGCCORE and ISO Application Profile support
INSPIRE compliant discovery service
Extensible FGDC, ISO, DC metadata support
Configurable search engine including spatial ranking algorithm
Federated searches to standards-based (CS-W), Web 2.0 (OpenSearch), or other types of search providers (CMS, Document Management Systems, …)
CSW clients (.NET + Java)
Data Discovery Widget for Flex
Data Discovery Widget for Silverlight
Data Discovery Widget for HTML
Ontology Service (java webapp)
WMC clients (.NET)
Publishing client (.NET)

We have some administration to do, but check back in later this month and next as we get the code out there. I'm looking forward to working with a larger community to further develop this product.

Data.gov Adds Geoviewer

2010-07-26T21:36:00.000-07:00

Today, Data.gov added a new capability to its growing arsenal of tools that allow for using the data the website makes accessible. The so-called Data.gov GEO Viewer has some interesting capabilities:

Data loaded into viewer in Real-time through web URLs – the viewer downloads data directly from the authoritative source. An ArcGIS Server Geoprocessing service uncompresses data if needed (.zip, .gz, .tar), transforms data to JSON, and streams this back to the flex viewer.
The GEO Viewer loads data in Web Mercator (if data or service supports it).Otherwise the GEO Viewer changes its basemap projection to Geographic Coordinate System and loads the data.
The viewer supports the following data types:

Map Services: OGC WMS, ArcGIS
Feeds: GeoRSS
Files: KML/KMZ, Shapefile

The GEO Viewer allows for mashing up multiple datasets, map services, and feeds in one view. It supports basic navigation using the keyboard (without the need to use the "shift+alt+F7+drag the mouse+release alt and mouse button at the same time"-like features...).
Set a basic color for the added data layer, set transparency for the layers, and use a swipe/see-through feature.
Basic identify operation on the added data.
Switching the basemap.

There are some limitations with this viewer, most of which are due to the fact that it downloads data from the source every time someone wants to see it:

File size limit of 10MB – Shapefiles and KML files can have large compression ratios. While the registered file in Data.gov may be an under 10MB KMZ file, this can easily expand into a 100MB KML that then is streamed as JSON features to the client. This simply takes time.
The information about the files is not enough to make an upfront assessment of whether the file is viewable or not. Almost every file in Data.gov is a .zip file. The GEO Viewer has to determine if it's dealing with an Esri Shapefile, OGC KML, Arc/Info Export (e00, remember these?), Microsoft Excel, CSV, or whatever format(s) until after it downloads the file. The metadata in neither raw data catalog nor geodata catalog includes this information. A result is that sometimes users will only be notified that the file type is not supported until after the viewer is launched.
Registration of content is not readily usable by an application (James Fee found one of these...). There are several registrations of content that link to web pages or web applications, rather than the actual data. In this case, the content is however also available as an ArcGIS Server Map Service (although that's not in the registration in Data.gov).

Are we there yet?

No. This GEO Viewer is not the end point. It's another step towards allowing users to interact and understand the data discoverable through Data.gov. The viewer illustrates the need to include more map services in Data.gov. Even registering map services alone may not be enough. In this world of service architectures, platforms, and such, we become more and more dependent on each other. Offering a service means signing up to a responsibility to keep this service running and available for an extended period of time.

Oh! And the proof of the pudding is in the eating! Here some samples:

My most favorite dataset on Data.gov: the locations and characteristices of world copper smelters.
For the patient folks: Active Mines and Mineral Plants in the US
My next house location: Geophysical Surveys of Bear Lake, Utah-Idaho
The dataset James was looking for: USGS Oil and Gas Assessment Database

Give it a whirl and provide your feedback to Data.gov.

Announcing the ArcGIS Editor for OpenStreetMap

2010-07-05T17:59:00.000-07:00

For a while, ArcGIS users have been able to use the OpenStreetMap (OSM) content as a basemap in ArcGIS Desktop or in web applications thanks to a republishing of this content through ArcGIS Online. After the earthquakes, we have received many requests from users of ArcGIS who want to contribute to OSM, but who prefer to use the editing capabilities of ArcGIS Desktop.

For users of ArcGIS 10 this is now possible using the new free add-on ArcGIS Editor for OpenStreetMap.

The ArcGIS Editor for OpenStreetMap is designed to help ArcGIS desktop users to become an active member in the growing community of users building an open and freely available database of geographic data.

The provided tools allow the user to download data from the OSM servers and store it locally in a geodatabase. The user can then use the advanced editing environment of ArcGIS Desktop 10 to create, to modify, and to delete data. Once the edits are complete, the edit changes can be posted back to the OSM server and become available to all OSM users.

The interaction with the OSM server is accomplished using as set of geoprocessing tools to download, to manage, and to upload data.

A total of six tools support the a disconnected editing like workflow: download data from OSM, edit locally, and upload the result back to OSM.

OSM has a very flexible data model, to support some consistency in created feature types. However for more focused data capture activities, such as those that occurred after the Haiti and Chile earthquakes, a more focused data model approach is suggested. To use the new ArcGIS 10 template feature, we have mapped the common tags used in OSM to attributes and feature types, created templates for these, and implemented suggested symbols.

Editing is straightforward. After downloading your work area from OSM, you use the normal ArcGIS Desktop editing features. There are some things to keep in mind in this first release:

Only simple and single part geometries are supported.
You cannot create features with more than 5000 nodes. The OpenStreetMap server has a limit of accepting geometries with up to 2000 nodes.
Deleting a point, line, or polygon can have an effect of changing the relation in which the feature participates.
Editing of OSM relations or super-relations directly is not supported in this first release.
Polyons generated from data downloaded from OSM may be corrupt. To be safe: run the repair geometry tool before starting to edit.

As with any multi-user editing environment, you may run into a situation where multiple users edit the same area. This results in conflicts when trying to upload your edits to OSM. In order to mitigate the conflict the ArcGIS Editor for OpenStreetMap offers a simple Conflict Editor to help resolve the situation. Best practice is to edit a relatively small area and to save back to OSM frequently.

We are releasing this first version of the ArcGIS Editor for OpenStreetMap. and are looking for feedback. More details on the tool will become available over time, including access to the source code, and enhanced documentation.

Enjoy!

Can I Have One NSDI with Some Confusion on the Side Please?

2010-06-08T20:38:00.000-07:00

In this age of publish first, then filter, and instant gratification, it is easy to loose some of the real questions out of sight. The merging of Data.gov and Geodata.gov (yes, that is the plan) raises some questions that have gotten lost in the excitement from the last week.

Here are a couple observations on the subject that could be made by anyone who has been following the two sites over the past year(s):

Geodata.gov harvests most of its content from over 300 other catalogs (visit the Geodata.gov Statistics tab and view the information on Partner Collections). Data.gov does not have this capability. These catalogs represent federal, state, and local government, academia, NGO, and commercial providers of geospatial resources (visit the same tab on Geodata.gov and view the information on Publisher Affiliations). Data.gov on the other hand focuses on content from the Executive Branch of the Federal Government. Where would the remaining content of Geodata.gov go? http://www.otherdata.gov?
Geodata.gov focuses on FGDC+ISO metadata with the industry looking at migrating to the new North American Profile of ISO 191xx metadata. Data.gov has developed its own metadata specification and vocabulary that is quite different from this. Just look at a details page on Data.gov to confirm this. What is the position on this subject of FGDC and other federal agencies who have created standards-based metadata for many years?
Geodata.gov has focused on the GIS analysts and first responders (check the original Statement of Work, I'm sure it's online somewhere). Data.gov seems to focus on a different audience (although honestly it's not entirely clear to me if that audience consists of developers or the general public. It’s a bit of both).
Geodata.gov has supported a number of user communities in two ways:

by allowing them to create community pages with resources beyond structured metadata that are of interest to those communities. The content in these pages is managed by the communities themselves. How should Data.gov support these communities of interest?

by supporting community-oriented collections that group metadata from multiple source catalogs. Examples are RAMONA (the states’ GIS inventory), the Oceans and Coast Working Group (interested in all content in the US coastal zone), and Data.gov (actually, this is also configured as a collection in geodata.gov). These collections are exposed on the Geodata.gov Search tab and in the CS-W and REST interfaces to the catalog.Where would these collections end up after a merger of Geodata.gov and Data.gov?
Geodata.gov has created a Marketplace where those who are looking for data and those who have plans to acquire data can discovery each other and collaborate. A dating service of a different kind. While not specifically targeted at the masses, isn't one of the key principles of NSDI to collaborate to reduce redundant investments?

Geodata.gov has created a search widget that has been implemented by several agencies such as the State of Delaware that enables searching geodata.gov directly from the website and thus getting access to state and other geospatial resources covering the area of the state. This widget can mean significant cost savings for agencies as they don't have to create their own clearinghouses. Will Data.gov provide such a role as well?
Through FGDC CAP grants several tools were built that work against the Geodata.gov REST or CSW interfaces. I mentioned some of these capabilities and the links to these tools in my recent blog post. Merging Geodata.gov and data.gov would ideally not break these investments.

It would be nice to see the passion that was expressed over the last week be repeated, but now discussing some of these and other questions that affect the geospatial community at large.

Building your own ArcGIS.com client

2010-06-06T23:12:00.000-07:00

ArcGIS.com provides a great collection of resources and, as Jack explains below, allows other people to discover the work ESRI users are doing.

ArcGIS.com includes a cool website, but as we learned when developing the Geoportal Extension, it also provides a RESTful interface. This meant we could offer users of the Geoportal Extension access to the information others are sharing through ArcGIS.com.

In the Geoportal Extension we allow distributed searches to go to ArcGIS.com. We implemented this early on in our contribution to the Group on Earth Observation

Realizing that many organizations aren't waiting for yet another portal, we developed a simple mechanism to integrate a search widget into any web page that would allow searching Geoportals. This has resulted in an HTML widget that can be embedded with 2 simple lines of HTML. By default this widget searches the Geoportal it is part of. But hold on, there's more!

The Geoportal can search external catalogs, including ones that implement the Open Geospatial Consortium (OGC) Catalog Service for the Web (CS-W), but since 9.3.1 it can also search... ArcGIS.com! Try it at the GEO Portal by going to the search page and selecting ArcGIS.com from the 'search in' dialog. You'll notice it searches ArcGIS.com with the keywords you give. This means any Geoportal 9.3.1+ is a client to ArcGIS.com.

But back to the widget.

Directing the searches from the widget to ArcGIS.com is possible by adding a parameter that instructs the Geoportal to direct the searches to the identified remote site. And thus here is a widget that searches ArcGIS.com. All it took was a minimal HTML like this:

<html>
<body>
<p>Search widget for ArcGIS.com </p>
<script type="text/javascript"

src="http://serverapi.arcgisonline.com/jsapi/arcgis/?v=1.3" ></script>

<script type="text/javascript"

src="http://geoss.esri.com/geoportal/widgets/searchjs.jsp?rid=ArcGISOnline" >
</script>

</body>
</html>

Using these lines you could embed ArcGIS.com searches in your own web page. Using this approach, you could build your own ArcGIS.com client. Take a look at databasin.org for a more sophisticated example.

To learn more about the options for the widget, visit the Geoportal Extension help pages.

PS: At version 10, the Geoportal will support federating searches to more than one remote catalog and also include ctalogs of non-structured metadata or even non-spatial content, such as Wikipedia, Flickr, YouTube, or your document management system. Try out the weekly release of Geoportal 10 at out public sandbox. Let me know if you find any issues. We are wrapping up development, but we're open to your feedback.

Accessing the Data.gov catalog through an open interface

2010-06-04T20:29:00.000-07:00

In its first year, Data.gov has grown from 47 datasets to over 270,000 datasets. These datasets aren’t actually hosted at Data.gov. The government agencies making these datasets available, host the files (or web services), and share them with the community through data.gov. But how did these datasets become discoverable at Data.gov?

Actually, the datasets are registered with Geodata.gov, a national catalog of geospatial resources that has been around for some 7 years and that “serves as a public gateway for improving access to geospatial information and data under the Geospatial One-Stop E-Government initiative”.

Geodata.gov provides access to almost 400,000 geospatial resources from over 300 partner collections from federal, state, and local government, as well as academia and commercial providers. Rather than having to sift through as many web sites, users can go to Geodata.gov and perform searches there. Creators of the geospatial resources can register this content with Geodata.gov if they choose to do so. From its inception Geodata.gov has aimed to be inclusive in the sense that it doesn’t matter what geospatial technology you use to create or consume geospatial data (or web services) in order to use Geodata.gov or its content.

This design principle of being open and interoperable applies not only to the content but to the site itself as well. Since its launch Geodata.gov has provided a search interface following the Open Geospatial Consortium (OGC) Catalog Service for the Web (CS-W) specification. Later geodata.gov added a RESTful interface that returns search results as GeoRSS, KML, HTML, and GeoJSON. These interfaces are intended to support using the content registered with Geodata.gov without using the website.

The RESTful interface has been used by the Carbon Project to develop a desktop widget that allows for content discovery on Geodata.gov directly on your windows desktop, as well as developers who have extended tools like NASA’s World Wind. ESRI has developed clients for ESRI’s ArcGIS Desktop and Explorer that use the CS-W interface to provide its users with data discovery capabilities. All these are free tools intended to help bring the content registered in Geodata.gov to the users.

So what does this have to do with Data.gov? Well, when Data.gov was in search for content (pun intended), it was just common sense to reuse the effort already put in a catalog of geospatial content: Geodata.gov. Since June 2009, Data.gov has been using the CS-W interface provided by Geodata.gov.

Federal agencies can mark the content they have registered with Geodata.gov for sharing with Data.gov. It is this subset that is discoverable in the Geodata Catalog on Data.gov and you can search this subset using the interfaces mentioned before, allowing you to build your own discovery clients to the content available in the Geodata Catalog of Data.gov and include spatial searching, advances filtering, etc. Features that are not (yet) available at Data.gov itself.

How? In the RESTful interface, simply adding the parameter isPartOf=data.gov will filter Geodata.gov for content that has been marked for sharing with Data.gov. A request for orthoimagery that is discoverable through the Geodata Catalog in Data.gov thus becomes:

http://catalog.geodata.gov/geoportal/rest/find/document?isPartOf=data.gov&searchText=orthoimagery&f=html

Doing this in the CS-W interface means creating an OGC CS-W request like this:

<csw:GetRecords xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:ogc="http://www.opengis.net/ogc" xmlns:ows="http://www.opengis.net/ows" version="2.0.2" service="csw" xmlns:dc="http://purl.org/dc/elements/1.1/" resultType="results"> 

  <csw:Query typeNames="csw:Record">

    <csw:ElementSetName>summary</csw:ElementSetName>

    <csw:Constraint version="1.1.0">

      <ogc:Filter xmlns:ogc="http://www.opengis.net/ogc">

        <ogc:And>

          <ogc:PropertyIsLike wildCard="%" escape="" singleChar="">

            <ogc:PropertyName>AnyText</ogc:PropertyName>

            <ogc:Literal>isPartOf:data.gov</ogc:Literal>

          </ogc:PropertyIsLike>

          <ogc:PropertyIsLike wildCard="%" escape="" singleChar="">

            <ogc:PropertyName>AnyText</ogc:PropertyName>

            <ogc:Literal>orthoimagery</ogc:Literal>

          </ogc:PropertyIsLike>

        </ogc:And>

      </ogc:Filter>

    </csw:Constraint>

  </csw:Query>

</csw:GetRecords>

Give this a try at this test page where you can post the above CS-W query, using the CS-W connector URL: http://catalog.geodata.gov/geoportal/csw/discovery.

More details on these interfaces to use the content of Geodata.gov and Data.gov’s Geodata Catalog is available in the GOS API Documentation.

Whether you want to use the RESTful interface or prefer the CS-W + XML approach, the content in Data.gov and Geodata.gov is yours to discover. Use that content to make a nice map or two. Please don’t use it to plan your strategy to take over the world.

Clouse Encounters of the Semantic Kind

2010-05-28T06:44:00.000-07:00

Explorers are we intrepid and bold
It was bound to happen. Some time ago I got curious about the whole semantic web thing. Working on the geoportal extension at ESRI, we're looking for ways to improve connecting users with producers of geospatial resources. With the advent of systems of systems (although sometimes feeling like turtles all the way down), assuming that a single catalog will do the trick is not an option. So I embarked on a journey into the world of linked data, RDF, and all the fun that comes with that

Out in the world amongst wonders untold
A couple months ago, I got invited to participate and present in a workshop at WMO about information access enablers. Tim Berners Lee suggested to the organizer to look into the RDF model as a way to allow linking data across organizations.

Equipped with a wit, a map, and a snack
So after seeing data.gov experimenting with SPARQL I felt it time to do some experimenting myself. Got some content from data.gov through the REST interface provided by geodata.gov (all 270,000+ geospatial datasets in data.gov actually are registered in geodata.gov and data.gov reuses this content through a web service. how gov 2.0 is that!), downloaded joseki, generated a Turtle file of the catalog, and had my own SPARQL server up and running. All while flying from Amsterdam to DC on my way from WMO to the Gov 2.0 Expo.

We're searching for fun, and we're on the right track
At Gov 2.0 I got a unique chance to sit down with TBL and discuss some of our work. You just don't pass on an opportunity like that! INFORMATION.ZIP. Later that day TBL met with Jack and it suffices to say that SPARQs flew through the room (pun intended). How to model spatial relations in RDF? How to handle relations that aren't explicitly expressed but are determined on-the-fly as a result of some question? What does 'nearby' actually mean?

Like any meeting with your professor at college, you leave said meeting with more work than you entered... I loaded various w3c documents, RFCs, and more prior to board the airplane for California.We're just starting to learn the possibilities of RDF, SPARQL. Providing a text box for someone to fill out an obscure query is not enough. But there already are some good examples available, such as the site This We Know.

to be continued...

PS: rdf:about="http://www.blogger.com/post-create.g?blogID=1395973636692118549"

foaf.rdf

2010-04-18T16:55:00.000-07:00

<rdf:RDF
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
      xmlns:foaf="http://xmlns.com/foaf/0.1/"
      xmlns:admin="http://webns.net/mvcb/">
<foaf:PersonalProfileDocument rdf:about="">
<foaf:maker rdf:resource="#me"/>
<foaf:primaryTopic rdf:resource="#me"/>
<admin:generatorAgent rdf:resource="http://www.ldodds.com/foaf/foaf-a-matic"/>
<admin:errorReportsTo rdf:resource="mailto:leigh@ldodds.com"/>
</foaf:PersonalProfileDocument>
<foaf:Person rdf:ID="me">
<foaf:name>Marten Hogeweg</foaf:name>
<foaf:title>Mr</foaf:title>
<foaf:givenname>Marten</foaf:givenname>
<foaf:family_name>Hogeweg</foaf:family_name>
<foaf:mbox_sha1sum>e67968237c1c331dd97df17ea80c345ba994548d</foaf:mbox_sha1sum>
<foaf:homepage rdf:resource="http://martenhogeweg.blogspot.com"/>
<foaf:depiction rdf:resource="http://2.bp.blogspot.com/_Z-JUhgCM_GI/SrVT1HiWyhI/AAAAAAAAABA/1s3c2HN0ng0/S220/marten.jpg"/>
<foaf:phone rdf:resource="tel:(909)-793-2853"/>
<foaf:workplaceHomepage rdf:resource="http://www.esri.com"/>
<foaf:workInfoHomepage rdf:resource="http://www.esri.com/geoportal"/>
<foaf:schoolHomepage rdf:resource="http://www.vu.nl/en/index.asp"/></foaf:Person>
</rdf:RDF>

What type of resource are you?

2010-01-10T19:11:00.000-08:00

As developers of discovery and access tools, we run into the situation where we discover a resource in a remote catalog and have to understand the specific type of that resource so that our clients can work with it. This is not a geo-specific problem. No one who has opened a link that ended in .pdf has ever been surprised that the resource on the other end of the URL was opened in Adobe Reader. Somehow my system recognized this to be a document and saw I have a client installed that can work with that document. This was not because of the .pdf extension, but thanks to the fact that the PDF came to me with a MIME type (maintained by IANA).

I found an old blog post on the OGC website where someone asked about dropping OGC-specific MIME types in WMS 1.3.0. The question remains unanswered in the blog since May 10, 2005...

I pose that defining MIME types for various geospatial resources (from file storage types like ESRI Shapefile to web services like OGC WMS) will benefit users of these geospatial resources and developers alike. Here I'm not speaking of the data/images obtained from these services, but (in OGC case) recognizing the service endpoint as such.

SDI for Everyone

2009-10-15T09:50:00.000-07:00

The topic of verbose metadata versus youtube-style metadata (a title and a video) in the context of Spatial Data Infrastructures is not new. Even publishers of geospatial content struggle with the verbose metadata standards that have been created over the years. Those metadata standards were not written with data discovery in mind. They resulted from the need for analysists to fully understand the data they were about to use to ensure it fit their purpose.

With the advent of the content sharing sites like Youtube or Flickr content sharing no longer was limited to the scientific/professional community. Everyone who is willing can share their content with someone else can do so now. With the increased ease of sharing comes a demand for an increased ease of describing the thing you're sharing.

If someone decides to share something, they do this presumably with the intent of someone finding that thing. If you are trying to sell your car on eBay, you will want people to find your car there and you'll try to describe your car such that you attract buyers. A picture of your car may not be sufficient in that case. On the other hand, you don't need to refer to the specifications of every part of the car either.

Different uses, different metadata.

Additionally, the tools used for discovery are different. In addition to going to a specific site (Flickr, Youtube) users expect to find the things they're interested in using their preferred search engine.

These two aspects apply to Spatial Data Infrastructures just as they do to the general audience searching for content on the Web.

With the ESRI Geoportal Extension we're aiming to answer to these two aspects: support different types of metadata and support arbitrary search tools.

This has led to supporting both the verbose FGDC/ISO metadata specifications as well as supporting the ability for someone to register a geospatial service and extracting information from the resource enough to support findability. This is supported on both the ESRI ArcGIS Server services as the Open Geospatial Consortium service types.

The second part of supporting arbitrary search tools is supported through a set of interfaces to the geoportal. These interfaces support both the 'traditional' interfaces as published by the Open Geospatial Consortium and ISO (CS-W 2.0.2 and ISO 23950) as well as OpenSearch or generic RESTful interfaces. In addition we provide an indexable sitemap of the content of the geoportal that follows the Sitemap.org profile. This profile is supported by the major search engines.

The Geoportal Extension REST interface supports alerting users of updates to the catalog through GeoRSS notifications that reflect a user's interest. The same interface supports output in KML, HTML, ATOM, and GeoJSON. This has opened the content of the Geoportal to many platforms and search tools. Geospatial users who have desktop GIS tools (ArcMap or the free ArcGIS Explorer) can plug in a simple search tool that leverages these interfaces so that they can find geospatial resources and directly use those in their GIS environment.

With Geoportal Extension we are looking to bridge the gap between discovery and verbose metadata and support both traditional interoperability specifications and the interfaces that are en vogue currently.

SDI for Everyone!

The proof of the pudding is in the eating, right? so here we go:

Geoportal Extension 9.3.1 SP1 work in progress
Geoportal REST interface supporting GeoRSS, HTML, ATOM, KML, and GeoJSON
Flex widget
HTML widget that lets you embed searches in your own web page
Google Gadget
Free search clients for ArcGIS Desktop and ArcGIS Explorer
Geoportal Extension Webhelp

Enjoy!

NSGIC 2.0

2009-10-12T07:59:00.001-07:00

Some things were different at NSGIC 2009 in Cleveland, OH. Perhaps it was the proximity of the Rock & Roll Hall of Fame that stirred things up a bit... This time the crowd wasn't just listening to the presentations, they were actively engaged in online conversations using twitter, following #NSGIC2009. People who weren't at the conference got to participate by responding to the posts and asking their own questions. The presentations are now available online at SlideShare, courtesy of NSGIC. While the conference is over the conversations will continue. To me, those conversations are one key aspect of realizing the NSDI and Gov 2.0.

During my presentation, I claimed that: sharing your current authoritative geodata through web services with open API will help build a platform for transparent and accountable government. Simple as that. Open up those data silos, let others use your data creatively to build applications.

I was honored to co-present with Jerry Johnston, GIO of US EPA. Jerry introduced the ChesapeakeStat program that will provide an avenue for publicly tracking and reporting progress of accelerating nutrient and sediment reduction throughout the Chesapeake Bay watershed, including federal lands. A multi-state and federal partnership that will result in a set of web services and applications built on those web services.

ESRI Inc Supports suchs public/private partnerships to collaboratively build a Gov 2.0 Platform, through the provisioning of Map Services and Tasks, a Content Sharing Program, Open Web Mapping API, and Open Source Sample applications. These and more are available at the ESRI resource center at http://resources.esri.com.

NSGIC 2.0

View more presentations from National States Geographic Information Council.

Stability in a dynamic world

2009-09-19T21:08:00.000-07:00

Technology is not unlike fashion. What was once considered hip and trendy falls out of fashion, only to returned in a retro-improved way after a period of time. I never realized this until I hosted a group of Dutch Waterboards at the ESRI Headquarters in Redlands, CA...

Seeing some of my former clients after some 5 years was a pleasant distraction from the day-to-day business of projects and product development. It provided an opportunity to recollect some of the work we did on creating a common data model for water boards in the Netherlands ten years ago and look at how the goals of that project were doing: share application development to reduce redundant investment, less dependency on a particular application vendor, bridge the information gap between organizational units and business processes, and others.

Although the data model has changed name, its contents are still very much alive. Over the years, the Waterboards have developed several client-server applications that connect to a single data store, thus integrating the various business processes within a Waterboard. All organizational units have the same definition and information for the objects they manage, including but not limited to waterways, hydraulic structures, permits, and numerous other aspects of water management. This would lead you to think: mission accomplished!

But the group of visitors expressed new desires that have come up in this past period that have lead to their study trip to the United States: further separate the layers of the application architecture or the use of new features in supporting software components, to name a few. Over time the client-server pattern has been followed by thin-client and other application architectures. More recently service oriented architectures and the enterprise services bus (or is it services-buzz?) are in-vogue. The accepted styles for user interfaces have changed with those technologies as well. Not that the current application wasn’t meeting the initial needs, but the needs have changed with the advent of new technologies and capabilities: how did we ever do without AJAX?

People trade in their cellphones, not because the old one is broken, but because the new ones have more cool features, and the availability of those features creates the need for them. This is the old supply-demand principle of a market economy.

This principle also applies to software technologies as well. Where a couple years ago the use of HTTP GET/POST protocols for the Open Geospatial Consortium (OGC) services specifications was well accepted, there now is a growing need to add support for SOAP/WSDL to these specifications. Not because HTTP GET/POST doesn’t work, but because the context in which the OGC services are being used is changing to use Service Oriented Architectures (SOA) that require the use of specific standards such as SOAP. Note that the data or the data model that is made accessible through these changing protocols is not affected by the particular choice of protocol.

Well, ever noticed what happens if you use SOAP (most noticable in the shower)? It dissolves and you have to buy new soap! New technologies will come for messaging, information exchange, presentation, aggregation, central versus distributed data management, and what not. Acknowledging this is half the victory of the technology battle: do what makes sense for the foreseeable future, follow the general trends of IT, and assess what and when new technology fits your business needs.

For the Dutch Waterboards, the constact factor in this 10 year period has been the data model, confirming one of the assumptions that lead to the definition of the data model to begin with. The tremendous effort that was put in analysing entity-relationship-diagrams, class-diagrams, data dictionaries, and other exciting materials, proved its value in a world of ever changing technologies.

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in October 2006

The Eye of the Storm

2009-09-19T20:58:00.000-07:00

We all know the cliché that in the United States the vacations are limited to christmas eve, president’s day and the fourth of July. Bosses get nervous when their staff asks for a full week off, and two weeks is generally called sebatical... You can imagine what happens after a four week vacation that ends on the day that Hurricane Katrina makes landfall in Louisiana.

It is like hitting the wall of the storm again, right after being in the quiet eye of the storm for four weeks. My mind was set to complete the new version of the Geospatial One-Stop Portal (http://www.geodata.gov) for which I am project manager at ESRI and to think about the next steps in this project.

Little did I know how my schedule would be affected by Hurricane Katrina that cost many lives, cost business owners their life’s work, and destroyed many local governments databases, IT infrastructures, and buildings.

Apart from the human rescue operations, many GIS volunteers went to the affected areas and helped recreate the data and maps needed by first responders using equipment and software donated by private industries from accross the United States.

Within a week the United States Geological Survey initiated a concerted and focused effort aimed at creating a comprehensive seemless database of geographic information for the affected areas. This meant collecting data from many sources, in many different formats, assessing which data was usefull for the new database, creating mapping of the individual data models to a common data model, loading this data into the new database, and making this data available to those people who needed it in the first place. Apart from this effort, data is being collected in the field by first responders, areal photography is being acquired, and satellite imagery of the area is becoming available.

The amount of data that has become available todate after Hurricane Katrina made landfall is enormous. With the initial response activities changing in to a recovery operation. The amount of reports, data, and analysis results of the effects of the hurricane and of the reconstruction of the area that will become available within the next year is mind blowing.

To find ones way in this sudden wealth of information, metadata catalogs and search capabilities on those catalogs will play a key role. Here is where portals suchs as the Geospatial One-Stop Portal can have a significant contribution. These portals act as the card catalog for a library, allowing you to browse through a description of the information rather than requiring you to walk through the entire library in search of that one book. The new generation portals such as the Geospatial One-Stop portal provides more than just a card catalog with a search interface. These new portals provide for collaboration tools that allow users and producers of geospatial information to communicate with each other about a specific topic. This collaboration can be through the sharing of working documents, listing of and linking to relevant news feeds from a variety of agencies, or by participating in chat rooms.

Directly after the storm made landfall, a community of interest was set up on the Geospatial One-Stop Portal that was populated with information as it became available. This unstructured collection of resources was useful at the time (it was all there was!). However, as the stream of avaiable data grew, and after the realization that this information channel would exist for many months, a more structured approach would be necessary. This structure was provided by metadata about the datasets, clearinghouses, and mapping applications, that was published to the Geospatial One-Stop Portal. Existing resources already available on the Geospatial One-Stop Portal was updated to include a simple keyword ‘Katrina’ (and later on ‘Rita’) to indentify resources as relevant for the response and recovery effort. The Geospatial One-Stop Portal has proven its tremendous value as a mechanism for the dissemination of key geospatial resources to users of these resources.

The hurricanes also made it clear that although we all love the magic of web services, there are situations in which the good old floppy is unbeatable. The fact that 1.4 Megabyte floppydisk, has been replaced with a 120 GB Firewire Drive aside...

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in October 2005

Traveling Salesmen

2009-09-19T20:49:00.000-07:00

With the laptop, the problem of the traveling salesman has found a new dimension. Perhaps it is even time to discuss whether the original criteria of a solution to the traveling salesman problem require reconsideration.

I’m sitting in Terminal 6 at John F. Kennedy Airport in New York, waiting for the flight back to California. For a while now, there is this gentleman looking at me and clearly something is bothering him. When I hear my boarding call and I unplug my laptop from the power outlet, he straightens his back and I sense a definite mood swing. Walking to the gate I turn around to double check that I took all my belongings and I see the man plugging in his laptop and settling in the seat I just occupied. He now overlooks the surrounding area as a king overlooking the area around his castle. Nothing can hurt him anymore.

In my trips to clients across the United States I have learned the locations of power outlets and phone jackets at different airports. Keep your eyes out for flocks of laptops scattered around pillars or phone booths. These are the signs that power or Internet connectivity is not far away.

Since time salesmen have tried to determine how they can plan their visit to the clients of the day. The essence of the traveling salesman problem is basically improving efficiency. In the past travel meant waiting for the transportation vehicle to arrive (horse carriage, train, airplane) or to get at the next stop.

Nowadays we have mobile offices and wireless Internet connectivity. So instead of looking at the pattern of the lights in the ceiling or the color of the carpet in the airline terminals, we can now spend our time preparing for a meeting, work through the list of e-mails that piled up during a meeting, or write columns for a GIS magazine.

There are some limitations to the mobile office though. One of those is battery power. The salesman of today has to bridge the flying time between airports and the time spent at an airport between two connecting flights. This translates into a basic GIS problem: select a route from A to B as a set of flying segments for which the flying time per segment is not more than available battery lifetime and for which the battery can be charged in the time spent between two segments. Account for loss of battery power due to shutdown and startup when the airplane takes of or lands.

Note that shortest distance is no longer one of the traveling salesman’s problems. A longer flight might result in more effective working time and may therefore be considered a more optimal solution.

Extending efficiency to 100% leads to an interesting situation. At one point, the battery cannot be charged enough to last the next flying segment, resulting in making the segments shorter. This however also results in more shutdowns and startups, which has a negative effect on the remaining battery lifespan. Thus segments get shorter and shorter. The traveling salesman gets stuck halfway to his destination… Traveling further is not sensible since it is more efficient to stay at the current location.

A solution to this paradox may come in time as technology progresses. Video conferencing or even virtual reality meetings will become possible in the future, finally solving the traveling salesman for once and for all: the salesman stays at the office! Until then sit back, relax and enjoy the flight.

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in April/May 2003

Address Management

2009-09-19T20:43:00.000-07:00

I assume you know your address. But do you realize how often you are asked for that piece of information? And how often have you received mail at your address that was meant for a previous resident? This time I want to discuss some of the issues of managing addresses and how they might be solved using the new buzz: web services.

We came to realize this fact once again upon moving to Redlands. We provided address information Social security, driver’s licenses, visa, utilities, tax, and (to some of our family) more important matters such as cable television and Internet.

For us simple folks, the administrative part of moving to a new address may sometimes be irritating but imagine that you are a utility company, a bank or the Internal Revenue Service. Not knowing where to send your bills or sending bills to the wrong address can result in a considerable loss of revenues.

Being a geographer, knowing where to send a bill is one thing, but knowing where your customers are is another. The well-known process of geocoding allows for geographic analysis that is beyond the extent of address-based analysis.

One of the prerequisites for the results of this analysis to be valuable is that the addresses used are accurate. Not only in the sense that it corresponds to the information that is analyzed, but also that the address actually exists and can therefore be located on the earth’s surface.

After capturing address information by an organization, it also propagates through organizations as part of information exchange, aggregation and reporting to (for example) higher government bodies. At any stage of this process, people verify the validity of address related information before actually using it. There is definitely room for improvement here.

In my last column I discussed software development in relation to geographic information systems. One of the laws of software development states that solving errors early in the development process saves as opposed to solving the problem at the end of the project. The same applies to having correct addresses. Instead of having a multitude of organizations checking the validity of addresses and spending amounts of time in the geocoding process, we could try to start out with correct address information at the source.

Those of you, who have actually set up a geocoding function, know that it uses a geographic dataset with street information and address ranges. And you also know that this dataset needs to be maintained as new streets get created on almost a daily basis. The decision for what area the street dataset is acquired and maintained greatly affects the cost of the geocoding function.

With the introduction of web services such as ArcWeb from ESRI, it is now possible to offer a high quality geocoding function at a low cost for organizations. The cost associated with maintaining the dataset is shared between a large number of users.

Applications pass an address to the geocoding web service and the result, consisting of a geographic location, a standardized (!) address and possibly a map of the surroundings of the address are returned to the applications. This is all done through agreed upon web interfacing standards, including as XML, SOAP, WSDL and UDDI. If necessary, the requests and results transmitted through the web can be encrypted when address information is considered sensitive information and privacy should be protected. Using an application independent transaction identifier, privacy protection can be enhanced even more.

Equipped with this new web service, the utility companies and all the other organizations can stop guessing who is living in my house, resulting in a better cost-benefit balance for them and less unwanted mail for me. Sounds like one of those win-win situations we’re all waiting for.

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in October/November 2002

GeoInformatics, Geography and Informatics

2009-09-19T20:21:00.000-07:00

The past years, the work I have done in the field of GIS is getting closer and closer to the roots I have in software development. Is it just my own experience or is the world around us changing?

When I starting my professional career it was with a hydraulic engineering company. I worked with the software department and developed applications to support flood early warning and flood damage assessment. After some years I started creating these applications using ESRI’s Arc/INFO (is it was spelled at the time), ArcView, and ArcIMS.

I remember a Saturday evening when a colleague and I were enjoying lasagna while working through lengthy pieces of SQL trying to figure out why the web application we developed did not return the desired result for the selected location. One of us was coding the thoughts the other came up with combined with his own ideas and interpretation. The problem had been bugging our development team for a while and as the deadline came closer we resorted to this extreme measure.

By midnight the problem was solved and we sat down with a beer and reflected on how the approach we took proved successful and whether or not that could be turned into more practical use. It appeared that the concept of ‘paired programming’ we practiced was one of the elements of a software development methodology call eXtreme Programming (XP, not to be confused with that recent addition to the existing family of operating systems).

That experience made me realize that developing a GIS application successfully depends on well-known software development principles just as much as any other non-GIS software projects. The fact that we started off with products that deliver a lot of functionality out-of-the-box does not change this.

It may even complicate things. Whatever development methodology is applied (RAD, DSDM, XP, Waterfall, RUP), an application goes through the process of design, coding, testing in different cycles of different lengths. But the final step to success always is user acceptance. When starting from a commercial-off-the-shelf product that is being customized, there will always be discussions when anomalies are found as to whether this is part of the customization and thus within responsibility of the developer or is part of the off-the-shelf product and thus within responsibility of the manufacturer.

The fact that this discussion takes place at the end of the project when budget is running out and both developer and client want the product to be finished, but working, adds to the complexity. An idea may be to introduce a second type of acceptance test, this time aimed at the developer! Whatever off-the-shelf product, data or document is supplied to the developer is subjected to an intake test and anomalies are noted and either accepted to exist or lead to modification of the supplied item.

And guess what? Formal acceptance of items delivered to the software team at the starting point of the project or during the project, was one of the things we introduced at this hydraulic engineering company when we started thinking about Software Quality Assurance; nothing new, but still refreshing in a way.

So after some years my interest in software development has been revitalized and I now again read about subjects as software process improvement and test process improvement and how these may contribute to the success of our GIS projects and thus to the success of our clients. And the success of our clients is our primary concern.

Appeared in GeoInformatics Magazine (http://www.geoinformatics.com) in June 2002

Traffic congestion

2009-09-19T16:10:00.000-07:00

Part of our moving to Redlands is to get used to dollars, ounces, gallons, and miles. Just when we thought we missed out on the change to the Euro, we find ourselves in conversions of our own. Fortunately, one thing has not changed upon moving to the Los Angeles basin: driving a car often means: follow the red lights in front of you…

Another stable factor so far has been the use of Internet. We still use the same free e-mail provider as we did when we lived in the Netherlands. We only use it more often and with more people than before.

There is a kind of analogy between the road network and the Internet. First of all, the Internet and roads are collections of connected networks that allow transport between two locations. The networks may differ in type or size. Through agreed standards it has become possible to have objects pass from one computer network to another, thereby allowing the object to travel further than the limits of the originating network. And similarly, when traveling through Europe, I never had to change tires when crossing the border between two countries.

Just as is the case with the Internet, bandwidth is important on the road network. Bandwidth on a sandy forest road is much smaller than on a 4-lane interstate. And people using both types of networks share a preference for high bandwidth.

The increase in network traffic is the source of the third analogy between roads and Internet: traffic congestion. No matter the size of your driveway or the horsepower of the engine of your car, you will get into a traffic jam just as you turn on the highway. And similarly it doesn’t seem to help to have a cable modem installed to surf the web when everybody else does the same and uses it at the same moment you do.

So, now we have seen that the two types of networks are similar and share the same problems, can we benefit from this knowledge? Perhaps we can. Over the past years we have been building more roads, thereby increasing the bandwidth. This was not enough to meet the increasing demands due to the need or desire to travel.

With Internet traffic a different development can be observed. In the early nineties the Internet was accessed through a 9600 bps modem, the happy few having access to a 14.4 kbps one. Since then data volumes have increased exponentially, now allowing us to serve GIS data and functionality over the Internet.

Apparently we have found some solutions that help to minimize traffic congestion on the Internet. Whether it is data compression (car-pooling), or the use of high bandwidth backbones in addition to low-speed home phone lines (treating local traffic differently from long-distance traffic), there should be something we can learn from Internet developments when designing new road plans or addressing traffic problems in our GIS consulting work. Indeed we already apply some form of packaging (as is done with information sent over the Internet) with the introduction of traffic information systems that guide us along a route that has the least chance of jams!

I do not pretend to have the solution to traffic congestion problems. But we tend to keep following a familiar line of thought in solving geographic problems, and that has not always helped us find a more permanent solution. Sometimes the solution to a problem is found in an unexpected location or at an unexpected moment. So be sure to always bring your notepad and pencil, wherever you go, just to make sure you don’t miss that one leap of mind.

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in April/May 2002

Precision Gardening

2009-09-19T15:23:00.000-07:00

After living in an apartment complex for three months we recently moved to a house of our own. What the Bureau of Land management does for the entire United States, I do for my 9000 square feet of garden. Working in the field of GIS I thought about applying some of the techniques available to help me managing my domain.

We thought that we paid a lot of attention to our gardens in the Netherlands. After all, we are the tulip country of the world. How surprised we were to see the amount of attention that is put to gardening here in Redlands. Our newly acquired garden has a built-in irrigation system and this is not a rare luxury, but can be found all over town. Of course, when considering that we live in a cultivated piece of the dessert, it is only a bare necessity to treat the garden properly.

But what is properly? It is not uncommon to see small streams of water flowing down the road, indicating that some garden is being soaked instead of watered. The questions of life for the new homeowner are when to water the grass and how much does it need, or does it need feeding? And what about the roof? I realized that these questions are the urban echo of farmers across the globe wondering how to improve the yield of their land while controlling the cost.

One of the big differences is of course scale. To distinguish different parts of a garden as opposed to multi-acre fields, the resolution of the information needs to be better than one meter I would say. The high-resolution satellites that are becoming more and more available are rapidly solving this.

Another point is that in our garden we try to keep the grass short instead of having it grow like a field of corn. I am not aiming at optimizing yield. My concern is to apply enough water to avoid my grass to dry out without drowning it. I would like a thermostat-like system that tells me when and how much to water the lawn.

Farmers who expect a high increase in yield when applying precision farming are prepared to invest. For us homeowners the benefits mainly consist of saving money on water. This means that if the precision gardening business is to be viable, it should be a low-cost service. Luckily we have one very strong point in favor over farmers. Homeowners come in large numbers. The same principles should apply as with cable television or utilities. Having the cable company digging a cable to a single house would make it very expensive. Sharing cost with other users is the key to success.

The system I envision accounts for the amount of rain that has fallen over the past period, the seasons, the type of soil in the area and such. It should be possible to enter the type of grass is used in my garden. Satellite images are combined with weather forecasts and soil types in the area. These data come from different sources, but with technologies such as applied in the Geography Network, this should not present a problem. A future generation of the system may even support searching for more accurate data that feeds in the model (local weather reports for example) or for competing models that promise minimal water usage while giving a nice green lawn.

Think of the size of the market, if one could sell this type of geographic services to every garden-owning family in the world. Being able to log in to www.precisiongardening.com and to see my garden on screen with hints where to apply water and how much would not only be really cool, but could also help save some on the water bill. And saving water is only a natural thing to do in the dessert.

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in April/May 2002

Relocation Based Services

2009-09-19T15:14:00.000-07:00

No, the title for this column is not misspelled and you did not miss a new development in the field of GIS. The term reflects one of the reasons for this column and my own recent experiences in relocating and the role location-based services appeared to play.

Location based services are sometimes defined as based on the position of the user in space. My opinion is that location based services need not be limited to mobile devices. Logging in to my office network from some desk and finding that my computer automatically configured a printer near me is one of the less obvious examples of a location-based service although it is available in many office networks. The point here is that the field of application of location-based services might be much wider than mobile devices only.

So what about relocation? Relocation has settled in my mind lately, since my family and I are about to move from the Netherlands to California. In the process of relocating, at least two distinct locations and a route between them play a part. First of all I wanted some information on our destination and typed 'go Redlands' in my browser. Apart from a list of 53 sites with interesting information, I also got a great offer for a video camera system that can be used for surveillance purposes. Unfortunately I'm not a US resident yet nor am I logged on to a computer in the US meaning that the offer is not for me...

These Internet marketing campaigns clearly lack a location-based service and did not read Alex van Leeuwen's article 'Geo-targeting on IP Address' in the July/August issue of GeoInformatics! But things are not as bad as they may seem. Part of relocation is to find a new place to live. Surfing the web taught me that realtors are clearly beginning to see the added value of GIS. Some time ago you were lucky to find a picture of the offered houses on the Internet. Nowadays, most real-estate web sites offer a map showing the location of the houses. Some even give additional information on the neighborhood, schools, demographics and such. To me these sites qualify as 'offering a location-based service'. The nice thing about the Internet is that once you've followed one of these links you enter a new 'world' of information and more links to follow…

Beware not to get lost in cyberspace. But then again, being able to get lost is one of the key properties of a world, isn't it? Fortunately the chance of my goods getting lost during the relocation is next to zero. I can actually track the relocation of my goods from my present to my future location. This means that even in the event that the container ship carrying my stuff across the ocean does sink, I will always know where they are. Isn't that comforting?

Location-based services are not a thing of the future anymore and we do not have to wait for UMTS or other high-speed mobile networks and Global Positioning System (GPS) enabled devices. Geo-targeting can be seen as the GPS of the Internet. The nice thing about this is that your IP address is always known when connected to the Internet, and that is independent of your physical location on the earth. That means that Internet services that make use of geo-targeting will travel with you, wherever you go!

We have seen that even in a common thing as relocation one already can experience the benefits of location based services. All of these services were offered through the Internet. This leads me to conclude that the Internet, with its links, and references, is perhaps the largest location based service provider around. This column will be my own contribution to the expansion of location-based services.

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in September 2001

Internet GIS: Dedicate or Integrate?

2009-09-19T13:17:00.000-07:00

The Internet plays an increasing role in GIS. Be it for publishing maps or for exchanging data. New GIS applications are Internet enabled. The current websites containing geographic information are often dedicated to one subject, while integration of different data sources opens up new possibilities.

My last project at ESRI Nederland consisted of creating a web site where professionals can find statistical water related monitoring data (http://www.waterstat.nl). The developed application allowed for geographical selection and for this purpose a so-called map service was created. In a presentation I gave at our annual user conference in the Netherlands, I used this map service to demonstrate the possibilities of one of the ESRI (http://www.esri.com/) products to use Internet data sources in addition to local data.

During my presentation, I realized that the map service was not created as a data source for a GIS conference. It was dedicated to serving an Internet application. This led me to visit other web sites that serve maps and there one can see a similar phenomenon. Interesting maps are being used within these applications. The available Internet maps could be used in many different projects. But this is certainly not common practice. This is a bit sad. After all, how many of us have convinced our customers that GIS is the means of integrating different data sources!

Internet is widely available to organizations, modern GIS products are able to access data sources over the Internet, and maps can be served through the Internet. These ingredients can be combined into applications that give us access to information from local and national governments, combined with commercial data and data created with a project. Multiorganization projects can use a common dataset where each party contributes by supplying a dataset dedicated to one aspect of the project.

Although technical requirements may have been fulfilled to a large extent, there still are some hurdles to be taken. Currently organizations are used to prepare datasets that are only used by the organization itself. The possibility of others using their data requires not only the willingness to share information. It also requires the notion that a dedicated dataset might be used in a broader perspective than the project the dataset resulted from.

For a dataset to be suitable to be integrated with other datasets, one has to know something about its content, its quality, its purpose and so on. Initiatives such as the Geography Network (http://www.geographynetwork.com) implement metadata standards that allow for the search for that missing peace of data. However, being able to find different dedicated datasets and put them on the same map is only the beginning of integration. Content standardization is just as important.

A good example is the development of a nationwide data standard in the Netherlands, used by water authorities (http://www.idsw.nl/standaarden/model/entiteit_relatie/). The good thing of this standard is that it is a result of an initiative from water authorities themselves. Different competing GIS vendors participate in this standard by building applications and extending the standard with new data models. These vendors are all members of the Open GIS Consortium. This means that both with respect to content and with respect to the technical side of things standards are available and in use. Dutch water authorities are now implementing Intranet applications based on this common data standard and some of them are even publishing their maps on the Internet. The step towards being able to use each other’s data is not a big one.

We will have to dedicate ourselves to integrating data. So be a publisher and give us access to your information. It will help us make better decisions and that is beneficial for you too!

Appeared in GeoInformatics Magazine (www.geoinformatics.com) in November 2001

Motto

2009-03-12T09:55:00.000-07:00

Explorers are we intrepid and bold
Out in the world of wonders untold
Equipped with a wit, a map, and a snack
We're searching for fun and we're on the right track

It seems we are indeed on the right track after reading Adena's analysis of the new features on Geospatial One-Stop and its summary on Slashgeo.

ps: that was Calvin and Hobbes

New Geospatial One Stop (GOS) Features Add Content to GIS and Mapping Applications

2009-03-09T12:50:00.000-07:00

Check out the What's New page on the Geospatial One-Stop Portal (GOS). It has some new features that focus on making the content more accessible for use outside of the website context.

What I specifically like is the new capability to perform searches in GOS from external Web applications using a REST API. The new REST API allows you to issue a simple URL string request to GOS and receive responses in any of three formats: GeoRSS, KML, or HTML.

Yikes! I'm blogging!

2009-03-07T15:53:00.000-08:00

Hmmm. So this is a blog... I'll have to get used to talking to no one (or all of you). Will anyone actually read what I say or am I alone in the desert? What do you do in such cases? We'll see what inspiration brings. As I'm working on ESRI's GIS Portal Toolkit I run into things around metadata, OGC specs, and such. I'm also trying to think about how GIS Portals and catalogs can help people find geospatial resources that aren't discoverable through your regular search engines. Those will be the kinds of topics I'll talk about here.