enviroCar invites you to use your car’s sensor data for exploring the effect of your driving style on environmental aspects such as fuel consumption, CO2 production, or noise emission. All you need is an OBD2 adapter (available at Amazon starting from 18,-€) and our enviroCar App.

enviroCar enables you to share your car’s sensing data. With your data you can contribute to better urban planning and smarter cities and answer questions such as:

• what are the actual spatial characteristics of fuel consumption in your city?
• how to optimize traffic planning to reduce emissions effectively?
• what to learn from average speed maps?
• …

The figure below shows the concept of enviroCar:

The analysis of collected data can result in great analyses such as this one, noise emissions caused by cars within a city:

Now, you are asked to contribute to the success of this project!

If you are as enthusiastic as us about the possibilities of such a platform, please SUPPORT us through our crowd-funding initiative on Indiegogo.

Also, please spread the word and LIKE us on Facebook and FOLLOW us on Twitter!

The core of each GIS is of course built around the spatial data (duh). So how we access that data (on a programming level) should be of prime importance when designing Ilwis-Objects. Some people would argue that the organization of data is of prime importance but I don’t agree with that. Organization should be  a technical derivative of how I want to access my data. I don’t care if there is a database behind my interfaces or a file based system or a service or…. I just want to do things with my data. Organization is important, but only insofar it serves the interfaces.
So what  do I require of my interfaces?

1. They must be simple! ( remember KISS). This is probably the hardest point. Paradoxical as it may seem but it is far easier to develop a complex set of interfaces than to develop a simple one. Complexity breeds complexity and thus grows at a very fast pace.
2. Things that are the same should be the same. This is a cryptic point as it states something obvious. Still, I seldom see a very rigorous implementation of this in the software I am familiar with. E.g. is a (Ilwis3) maplist the same as a rastermap were only the nature of the pixel value is different ( a array instead  of a single value)? Arguably yes, so why are there different classes? It gets more interesting with vector maps. Is a point different from a polygon or are two spatial different points always different things? I will investigate this one further down below
3. Natural integration within the C++ STL style of programming. The STL is a core library of C++ that (among other things) abstracts algorithms from data types. The reason why this is important is that it generalizes and simplifies the way how we can write algorithms tremendously. For example I rewrote the resample algorithm from over 150 lines of code to 8 lines of code.

(more…)

The Sensor Web community has published a new beta release – “beta2″ – of 52°North’s implementation of the OGC SOS 2.0 standard. The new 52°North SOS 4.0.0. contains improved components and new functionality. Here is an overview of the improvements and new features:

• Dynamic WSDL generation for SOS 2.0, can be queried via http://[HOST]:[PORT]/[WEBAPP_NAME]/wsdl [new]
• Caching of service metadata [improved]
  • Serialize cache to file and load file on startup [new]
  • Update cache after transactional operations without querying the database [new]
• A new SosEventBus fire and listen to events, currently used by cache update after transactional operations [new]
• WaterML 2.0 encoder for observations [new]
• GetDataAvailability operation (request the availability of data) [new]
  GetDataAvailability request example from Test Client
  
• DeleteObservation operation [new]
• RESTful binding [new]
• SOS 1.0.0 support for GetCapabilities, DescribeSensor, GetObservation and GetFeatureOfInterest (contributed by Alexander Kmoch and Shane StClaire of Axiom Alaska) [new]
• Example data locations refer to our partners’ locations [improved]
• Enhanced administrative back-end [improved]
  • GUI to en-/disable operations, encodings and bindings [new]

  Example for binding administration
  

A large item for the next release will be the revision of the database model. The goal is a simplification of the model and the possibility of a subdivision into a Core and a Transactional module which can be used separately.

For further releases we have many more improvements planned – comments are welcome!

The implementation of the 52°North SOS 4.0.0 beta2 release has been performed in the context of the European EO2HEAVEN and GEOWOW projects.

A downloadable zip archive of the new beta release contains the sources, as well as the binaries. Release requirements and installation and configuration information are documented in the 52°North wiki.

Last week I talked a bit about what connectors are supposed to do. As mentioned there, their main task was to translate external representations to internal ones. This week I want to focus a bit on the internal representation. After all, that is what people will use when programming with ILWIS-Objects.

The design of the internal representation leans heavily in some ways on the existing implementation; in other ways, it deviates sharply from that. It was/is maybe somewhat surprising that an 18 year old design is still very relevant these days. At a high level, the data structure has not changed that much. We still talk about data layers and coordinate systems, the problem of the data’s semantics still has to be addressed and tables are still tables. What has changed is the nature of the data itself. Where 2D data was sufficient in the past, we now talk about 3D, 4D and even 5D data. We see the size and availability of data sets explode and we see the complexity of relations between data sharply increasing. So the claim is, while the nature of data certainly has changed, the overall structure has not changed as much.

So what is this structure? What is this ILWIS 3 inheritance which we will more or less port to ILWIS-Objects? The backbone of ILWIS 3 was a set of classes that were all derived from a base class called very creatively : IlwisObject. All major points of GIS/RS data organization were mapped onto classes in that organization. Please see a simplified picture of this below.

Last week I wrote about the high level design and structure of the next generation of Ilwis. This week I will focus on one of the most important parts of it, the connectors. In the picture of last week (part of it below), they made up the whole lower part of the second diagram