[OSM-dev] dev Digest, Vol 92, Issue 3

[Sandor Seres]

Hi K. Krueger and all the others working with vector tiling and vector
rendering development and applications.
Are we doing something illegal?
Some well known large companies have got patent on more or less the same
subject: Vector tiling and client rendering of tiled vectors.
Look at these patents/subjects:

http://www.google.com/patents/US7925100?ei=rGKKUM7QC6iA4gTw14DoDg

http://www.google.com/patents/US7734412?dq=vector+map&hl=en&sa=X&ei=rGKKUM7QC6iA4gTw14DoDg&sqi=2&pjf=1&ved=0CDcQ6AEwAw


The owners pretend to cover/protect nearly anything regarding vector tiling
as we understand it today and rendering of such vector data on the client
side.

Now, if we strictly interpret the patents, yes, we are doing something
illegal. But at the same time, we may raise several questions here:

-How was it possible to get patent on something that has been in use (and
books and courses) from the birth of graphic terminals (from mid 1980s)?

-Do we need to take these patents seriously or we should just ignore them.
If we have to respect them, we may just give up any tiling development,

tiling based transmission and rendering. Shortly, development of any
efficient vector based mapping.

-Is it really so easy to get patents (in certain parts of the world) on
such a general and banal methods/subjects like vector tiling and rendering?
Well, one should then try to get patent on how to use knife and fork while
eating (yet we do this in hundreds of years).

I am convinced that these companies were fully aware that there is pure
innovation (if any) in the related patent applications. The intentions most
probably was to provide a juridical weapon
for commercial fights/extortion latter.

Can some of you, more familiar with with the related laws, comment, give
advise on this issue, please?

Best regards, Sandor.

2012/11/4 <dev-request at openstreetmap.org>

> Send dev mailing list submissions to
>         dev at openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.openstreetmap.org/listinfo/dev
> or, via email, send a message with subject or body 'help' to
>         dev-request at openstreetmap.org
>
> You can reach the person managing the list at
>         dev-owner at openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dev digest..."
>
>
> Today's Topics:
>
>    1. Compressed vector tiles with mod_tile? (Kai Krueger)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 03 Nov 2012 22:06:38 -0600
> From: Kai Krueger <kakrueger at gmail.com>
> To: dev at openstreetmap.org
> Subject: [OSM-dev] Compressed vector tiles with mod_tile?
> Message-ID: <5095E9CE.5090805 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello everyone,
>
> I was playing around with vector tile rendering and in particular with
> Cover[1], which was a GSoC project this year. It can act as a tirex
> backend plugin and thus enable the standard tool chain of mod_tile/tirex
> to serve json vector tiles, including the caching and expiry, queuing
> and load management mechanisms that are part of that stack.
>
> Overall this works very well in combination with e.g. KothicJS[2].
> However, as text based json is not very space efficient, Cover stores
> the json compressed in the metatiles.
>
> Mod_tile can't yet natively deal with this and doesn't automatically set
> the HTTP header Content-Encoding: gzip and I'd like to fix this.
>
> The question is, should it simply be another configuration option in
> tile layer specification, or should the meta-tile format be changed to
> include this information?
>
> In the latter case the easiest way to store this information would be to
> include it in the first 4 bytes. Instead of "META" they could then be
> e.g. "METZ" to indicate the content of the metatile is gzip encoded.
> This would allow things to be completely backwards compatible and not
> interfere with raster tiles served by mod_tile.
>
> If a bigger version change of the meta-tile format would be the best
> idea, are there any other changes that would be sensible to do at the
> same time?
>
> For example, one could potentially store the md5 sum of each tile in the
> metatile header. If tiles are in memory, I think calculating the md5 is
> at least partly the bottleneck in serving tiles. On the other hand, I am
> not sure if that really is any real concern, as I can get over 2 Gbit/s
> at 20000/s tiles out of my laptop in benchmarks. So I suspect in real
> world scenarios other elements of the system bottleneck long before the
> speed of mod_tile becomes an issue.
>
> Kai
>
>
> [1] https://github.com/mdaines/cover
> [2] https://github.com/kothic/kothic-js
>
>
>
> ------------------------------
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev
>
>
> End of dev Digest, Vol 92, Issue 3
> **********************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20121104/97c3eeca/attachment.html>