It’s been awhile since we’ve written on the Mapufacture blog. That’s because we’re busy finishing up a number of great additions to Mapufacture and projects using Mapufacture. The team is all gathered out in San Francisco for several conferences and high-bandwidth brainstorming and development. While the tools like instant messaging, IRC, wiki’s, and code repositories make location-independent teams possible, nothing is better than physical proximity to solidify ideas and efforts.

In a couple of weeks we’ll be demoing at the OGC Technical Committee Meeting on the power of mixing OGC WMS interfaces with KML visualization and large GeoWeb datasets. It’s been an interesting, and enlightening 6 months working with the OGC on standardization and advancement of the KML. There have also been a number of discussions in the larger geo-community on Atom links to OGC services, OpenSearch-Geo interfaces to KML and pagination link within KML. We’ve been adding these quietly to Mapufacture and in the near future we’ll have more information on why it’s useful.

We’ve also been working with a number of really great projects in advising and building their collaborative mapping solutions. These are really grass root projects that need to easily bring together data from a variety of sources and systems, and then visualize these and share them back out. With Mapufacture we’re showing them how easy this is, and doesn’t disrupt their workflow, but actually fits into it.

We’re also slowly improving the user experience of finding data and building maps in Mapufacture. We want it to be easy for non-GIS experts to easily build geospatial visualization, so understanding the expectations and workflows has been interesting. We’re always looking for more feedback and will soon be opening some community tools for more Mapufacture users to share their experiences and ideas. You can also always ping us at human@mapufacture.com for immediate feedback.

Happy Mapping!

The UNDP Eastern Europe and Central Asia Bureau had a major relaunch of their Environment and Energy website for a major ministerial meeting in Belgrade last October. Maps were a big feature. And those maps were produced by Mapufacture Inc, in part utilising mapufacture.com.

There were two main tasks. A system to geotag UNDP environment projects, and a pretty map display. We decided to do both decoupled, in their way, from the UNDP CMS. Through RSS/GeoRSS it was just easy to link together the UNDP CMS and Mapufacture. The CMS produced an RSS feed of projects, and Mapufacture was set up to aggregate this feed. This was then made available for UNDP users for item level editing — dragging and positioning on the map. And as usual, Mapufacture made this feed available for export as GeoRSS, which was aggregated back by the UNDP.

Item level editing? Yes. Mapufacture has a lot of features built up but not just yet ready for launch, which line up even greater control over the GeoWeb for our users and customers. So from existing feeds, “private” copies can be made for editing, while still keeping them up to date from the source, or feeds can be created from scratch, and editing access controlled, etc. Sure elements of this have existed for a while here and there, but combined with Mapufacture’s existing tools and future features .. I’ll just say I’m pretty excited by what this all will offer.

Making a pretty map from that GeoRSS feed didn’t involved Mapufacture direct, but did invoke all our map making skills and hacks. Used Mapstraction to easily build marker filtering and brought back MGeoRSS for greater control over the loading of GeoRSS feeds — GMaps native GeoRSS handling just isn’t nuanced enough. The biggest trick was getting the map to display above the page. We were working within the limitations of the UNDP templates — and the middle column just didn’t provide enough space for the map to breath. Starting from leightbox I got the map overlaying on top of the other content properly .. that took a good deal of tweaking! And it uses anchors so that the back button works correctly and all.

So a fun project overall with the UNDP, pushing forward their technology, one of several I’m working on at the moment — not all map related but pretty interesting stuff. And we pushed forward Mapufacture. Perfect pushing.

Stefan Geens of OgleEarth wrote up an interesting comparison of Google’s recent “collaborative mapping” feature and other tools like Tagzania.

In the end, he posits that neither solution is quite perfect, but suggests a solution.

Ideally, we’d have a tool where an owner is in charge of a map to which anyone can contribute their own placemarks, no-one can alter others’ placemarks, and where the owner can weed out the spoilsports. In Tagzanian parlance, that would be the equivalent of “owning” a specific tag name, and being able to disallow inappropriate placemarks from using it. Neither Tagzania nor Google Maps gives us that kind of tool at the moment, but Tagzania’s comes closest to what we need.

Well, this is a feature supported by Mapufacture, and in fact a primary aspect of the benefit of a geospatial aggregation system.

Users can generate their KML or GeoRSS with whatever tool they want: CMS, Blog, Platial, MyMaps, Tagzanize, and the map “curator” can import everyone’s feed/document.

Then users can each update or alter their own feed and these edits will be consumed by Mapufacture.

Mapufacture doesn’t currently support single editing by a curator of individual items, but they can remove or hide individual feed sources. And of course, they could also take the aggregated GeoRSS or KML document from Mapufacture and drop that back into MyMaps or something else and then modify things that way.

That’s the nice thing about these open standards, it allows users to choose how they want to mix and match their data with the appropriate tools.

You can now take Mapufacture maps and feeds and put them on your GPS.

That third green button links to the GPS page for the feed/map. We’re still thinking about good iconography for GPS.

On the GPS page, you can download GPX (supported by most all synchronization software). Or if you have a Garmin GPS, you can use the Garmin Communicator plugin to download directly to your device to your device.

A nice one to try is the Wikitravel GPS export.

GeoRSS on your GPS is pretty woo!

If anything positive is coming out of the devestation in California, it’s the responsiveness of the GeoWeb .. lack of information is not a factor in the response.

FortiusOne is collecting data and visualizing. Chris Schmidt is building an impressive collection of sources here, including MODIS layers, KML, OpenStreetMap, and the latest processed diy aerial imagery from PictEarth.

We’re building up an aggregated view on Mapufacture. The time navigation might be particularly useful.

The past few weeks have been exciting for the GeoWeb. The concept of a fluid, openly accessible, device independent, interconnected network of geographically keyed data has great mindshare among the technologists and in the press. Practical and business developments mean its soon coming to reality. And from a hack two years ago to growing startup, Mapufacture is doing what it says on the tin — helping to build the geospatial web — through aggregation, openness, and engagement. First the news from the web, then our position.

Here’s what we’ve been tracking. Last week Platial acquired Frappr. Congrats to them — they’re all good people. This kind of consolidation shows a maturation in the space, a joining up of similar ideas that will lead to new market niches. And directly for a richer GeoWeb, perhaps we’ll now see GeoRSS out of frappr. Microsoft exposed their new geo-index of GeoRSS and KML within Live Search. Functions similarly to Google geo-index — an additional layer of search results for user facing queries. The Dash net-connected GPS will load GeoRSS, a powerful mobile navigation view on the GeoWeb, which hints at even more open collection of geodata .. perhaps paired with OpenStreetMap for an alternative to TomTom/TeleAtlas-Nokia/Navteq. FortiusOne, in building their geodata, wonder aloud again over openness — with the emerging GeoWeb, won’t all data be really free? Platial, ever sharp on the bottom line, sketch out how free and open data could create business opportunities.

Mapufacture’s contribution is to aggregate the GeoWeb. Data and services, in web or even traditional GIS formats, collected together from across the GeoWeb, are explorable, searchable, and reusable. We’re committed to doing this openly .. so our catalog of sources can be browsed by human or machine, sources easily added, and collections and slices and views on geodata are redistributed as GeoRSS and KML for reuse in any way. The service itself gives sophisticated views and choice — we’re agnostic to web mapping APIs and support OpenStreetMap, and push the limit of visualization with time navigation and in browser 3D (ala FreeEarth). We want the GeoWeb to be accessible everywhere, so there’s views for Mobile devices, widgets, and soon GPS (net connected or not) and even that old favorite - Paper! We work hard to make this all accessible to non-mapping geeks, and at the same time extend the technology for developers with work on standards like OpenSearch Geo, KML 2.2.

We want to integrate with everything. We want to integrate with your service and data. And we want to improve, continuously. Any ideas or plans at all, drop us a line on human at mapufacture dot com.

We’re excited to announce the release of Mapufacture Mobile. All your maps and feeds are now available whereever you are, and geolocated to your position. We partnered up with uLocate to develop our widget on their very powerful, and easy to develop for, WHERE platform.

Mapufacture Mobile is an extension of the website. Through the website users can find interesting feeds and sources and put these on maps in various areas of interest. For instance, you can build a map of your community with local government notifications, weather reports, news, and friends’ locations. You can also build a map of a city you are traveling to with the locations of your hotel and venues, travel information, and restaurants.

Then, using Mapufacture Mobile, these maps are then available and show nearby items from the selected feed sources. So your community map would show news, events, and friends that are nearby using the geolocation on Mapufacture Mobile. Similarly. when the you move, new nearby items are shown and can be viewed on the map. Individual feeds that user has favorited are also available to view as desired, sorted by their distance from you.

Think of it as a geolocated, mobile KML and GeoRSS reader.

Besides the user’s own maps and feeds, Mapufacture Mobile allows you to view any feed or map that covers the area you are in. So if they are in a new city, or looking for some new local information, you can just view other feeds and maps made by other users.

Mapufacture Mobile also provides a general search mechanism to search the entire Mapufacture geoindex for any interesting items near you. These can also be shown on a map to give you an idea of the layout of the area around them and find interesting and informative things around you.

Mapufacture Mobile is currently only available on Sprint phones through the WHERE platform, but as the platform expands, we’ll expand with it. We also plan on offering mobile interfaces through a variety of other systems that we’ll announce in the near future.

The Mobile version was originally released at Where2.0 this year. You can find the uLocate Press Release and the O’Reilly Radar post. Since then we’ve added a lot of enhancements both to Mapufacture and Mapufacture Mobile.

To read more information on Mapufacture Mobile, and how to use it, check out the Mapufacture Mobile details page.

Mapufacture is part of a demonstration for GEOSS (Global Earth Observation System of Systems) in visualizing geospatial data from environmental fire sensors via GeoBliki that threaten powerlines in South Africa. Fire threat and detection feeds are combined with powerline infrastructure data to create a map and aggregated dataset using Mapufacture. There is a demo video that illustrates the process that will be used at GEO plenaries in Washington DC and South Africa.

GeoBliki is an open-source sensor-web software that handles intercommunication with satellite infrastructure for accessing and tasking satellites. It uses open geodata standards like GeoRSS that enable other software, like Mapufacture, to easily access and share its data. From Mapufacture you can then get the aggregated feeds in GeoRSS and KML, or as an embeddable map that you could put into a website.

There was a very good discussion today during the OWS-5 Agile Geography telecon - with almost all attending interested parties participating and a lot of good points brought up.

The foremost is a clarification of the goals and purpose of the OGC Web Services Testbed. The testbed is important to remember that it’s partially a venue to experiment and brain-storm on future standards. It is not an actual formal development of the standard.

In the OGC, as I understand it, a testbed is used to formulate, and implement, potential standards. Then a summary report and presentation is made to the OGC Technical Committee (TC). The TC then actually decides and votes on the standard.

So the current work that has referred to “KML3″ should be construed as hypothetical development. But, it also seems why it’s all the more important to have many users, developers, thinkers, hackers share their thoughts and example implementations now - while the iron is hot and malleable (to make a bad metaphor).

The Goals

One original goal, that wasn’t clear to me (and therefore reflected in my posts) was the primary desire to just determine and demonstrate the ability of existing OGC services to generate KML 2.1/2. This means showing how to take a WFS service that outputs GML, apply SLD, and get KML with styling. Or do the same with WCS or a WMS (just as KML vectorized data). Then to point out any small problems with KML 2.2 that make this conversion difficult.

This is definitely a useful goal - but I don’t feel that was made clear from the beginning. I also don’t think it will be that difficult - but since Mapufacture already outputs KML natively, I’m not sure - which then I imagine does make the case for having a testbed to show that.

Other goals that have been discussed, but just haven’t been blogged (or documented) include: KML as Context document, KML and GeoRSS interoperability - though I blogged about it previously and have heard general acceptance of the ideas, Sensor streaming, and styling imported geometry.

I’ll cover some of these in follow up blog posts.

Hopefully that clears up a little the OWS Testbed goals. Mapufacture is new to the OGC process, though I don’t think it’s very well understood in general amongst the geo-community from outside the OGC. So as we learn and figure things out, hopefully we can help share this information with others.

As part of the OGC OWS-5 work, the committee has a telecon every Tuesday afternoon. This is to ensure that progress continues throughout the 6-month project and any issues are raised early.

At this week’s telecon there was general agreement that there haven’t been too many concerns publicly raised about the current proposed KML modifications - and that in the next month the various participants would each prototype parts of KML 3 that are pertinent to their products.

For Mapufacture, we’ll be prototyping the updated KML Core, Metadata module, Service Links, and a Mobile version of KML3.

We agreed on a couple of other things as well regarding the scope of the OWS-5 effort. We won’t be addressing the possibilities of external schemas. Also, we won’t, as OWS-5, work on KML AtomPub (APP).

This doesn’t mean no one should - in fact Sean Gillies and Charlie Savage are getting together a demo interop that Mapufacture will participate in to work out APP with geo-apps, including possibly using KML as the content encoding.

No issues?

I did say there were no publicly raised issues. However, there are rumors of privately raised concerns about some of the KML concepts, especially as related to styling, by developers that have a lot of experience developing KML visualization clients.

However, despite multiple requests by individuals, and the committee, these developers, or company, have not yet shared their experience, thoughts, or concerns with the committee. This is surprising considering this company is a core part of the Agile Geography thread and has a vested interest in the future of KML.

Why they would choose to not share their insight either means they’re too busy, open to new suggestions and really want the insight of developers and users not intimately tied to a particular implementation - or that they don’t really care about the public standardization of KML and will do what they want, regardless of what OGC decides for KML.

I hope they are just waiting to see what emerges, and in the end they’ll completely support the standard. However, based on their experience and supposedly having gone down some of these roads, it would be very appreciated if they would offer their advice.

Other standards

While not within the scope of KML3 and OWS-5, the committee is somewhat participating in other working groups within the OGC - which is usually referred to as “Mass Market”. The OGC will be proposing standardizing on the proposed Geolocation in HTTP headers draft spec.

Need feedback

No one currently on the committee currently is heavily involved with 3D visualization. We would definitely welcome feedback on features, standards, supports, and use-cases you would like to see in KML for supporting models, visualization, and immersive reality. Should KML support X3D? Only Collada? Do you want to specify linking of bodies in KML?

FOSS4G

As the last item of business, we agreed that we’re going to try and get a demo together for FOSS4G of the current spec. This will mean various implementations of Metadata, Styling, Service Links to play with in your own clients and server systems.