Thought about Vectors -- The power of client side rendering

The problem is basic, provide rich interaction with features to users. After all... they all know about Google Earth.

Having vectors rendered on the client allows richer interaction than WMS such as highlight on hover, edition of features, interaction between the map and another component such as a list, show and hide of individual features, etc.

This power comes at a cost, performance can quickly degrade as the load increases, therefore vectors should be used carefully.

Different standard come to my mind: KML popularized by Google, used in Google Earth, Google Map defines a presentation model. WFS standardized by the OGC specifies the behaviour of a service that provides transactions on and access to geographic features in a manner independent of the underlying data store.

So KML provides presentation while WFS provides data. What do your user really wants? If the user is a geotech he wants data, if your user is a system, it wants data, but if your user is a normal guy he wants to visualize information.

Both standards can be used to bring vectors to the clients, both standards have pros and cons. I will discuss them individually in a subsequent posts.

Thanks for reading! Let me know what you think about it.

Thought about OGC WFS-T -- Enforce Business Rules in Geospatial Edition

The problem is common; allow users to create, modify and delete features. Great, lets use WFS-T, what a nice fit! But...

Example use case:

The user creates a new address (point) on the map. He selects the address position and then has to fill other attributes. Civic number, Street Name, Postal Code, City, Country.

So the user already selected the x,y location for the feature, why should he have to fill the street name, the postal code, the city, the country?

Here is why, It is not possible to enforce any kind of business rules based on the position of the feature we are editing; or based on any other attribute. The describe feature type request should have an optional feature parameter.

Example of a describefeaturetype request:
http:///?request=describefeaturetype&service=wfs&version=1.1.1&outputformat=xmlschema

The solution? In a perfect world, WFS-T should take this use case in consideration for its next revision, so that open source or vendor implementations resolve the issue.

Thanks for reading! Let me know what you think about it.