Hi K. Krueger and all the others working with vector tiling and vector rendering development and applications.<div>Are we doing something illegal?<br>Some well known large companies have got patent on more or less the same subject: Vector tiling and client rendering of tiled vectors. </div>
<div>Look at these patents/subjects:<br><p><a href="http://www.google.com/patents/US7925100?ei=rGKKUM7QC6iA4gTw14DoDg">http://www.google.com/patents/US7925100?ei=rGKKUM7QC6iA4gTw14DoDg</a></p><p></p><p class="MsoNormal"><a href="http://www.google.com/patents/US7734412?dq=vector+map&hl=en&sa=X&ei=rGKKUM7QC6iA4gTw14DoDg&sqi=2&pjf=1&ved=0CDcQ6AEwAw" target="_blank">http://www.google.com/patents/US7734412?dq=vector+map&hl=en&sa=X&ei=rGKKUM7QC6iA4gTw14DoDg&sqi=2&pjf=1&ved=0CDcQ6AEwAw</a></p>
<p class="MsoNormal"><br></p><p class="MsoNormal">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.</p><p class="MsoNormal">
Now, if we strictly interpret the patents, yes, we are doing something illegal. But at the same time, we may raise several questions here:</p><p class="MsoNormal">-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)?</p>
<p class="MsoNormal">-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,</p><p class="MsoNormal">tiling based transmission and rendering. Shortly, development of any efficient vector based mapping.</p>
<p class="MsoNormal">-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).</p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal">Can some of you, more familiar with with the related laws, comment, give advise on this issue, please?</p><p class="MsoNormal">Best regards, Sandor.</p><p></p><div class="gmail_quote">2012/11/4 <span dir="ltr"><<a href="mailto:dev-request@openstreetmap.org" target="_blank">dev-request@openstreetmap.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send dev mailing list submissions to<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:dev-request@openstreetmap.org">dev-request@openstreetmap.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:dev-owner@openstreetmap.org">dev-owner@openstreetmap.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Compressed vector tiles with mod_tile? (Kai Krueger)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sat, 03 Nov 2012 22:06:38 -0600<br>
From: Kai Krueger <<a href="mailto:kakrueger@gmail.com">kakrueger@gmail.com</a>><br>
To: <a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
Subject: [OSM-dev] Compressed vector tiles with mod_tile?<br>
Message-ID: <<a href="mailto:5095E9CE.5090805@gmail.com">5095E9CE.5090805@gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
Hello everyone,<br>
<br>
I was playing around with vector tile rendering and in particular with<br>
Cover[1], which was a GSoC project this year. It can act as a tirex<br>
backend plugin and thus enable the standard tool chain of mod_tile/tirex<br>
to serve json vector tiles, including the caching and expiry, queuing<br>
and load management mechanisms that are part of that stack.<br>
<br>
Overall this works very well in combination with e.g. KothicJS[2].<br>
However, as text based json is not very space efficient, Cover stores<br>
the json compressed in the metatiles.<br>
<br>
Mod_tile can't yet natively deal with this and doesn't automatically set<br>
the HTTP header Content-Encoding: gzip and I'd like to fix this.<br>
<br>
The question is, should it simply be another configuration option in<br>
tile layer specification, or should the meta-tile format be changed to<br>
include this information?<br>
<br>
In the latter case the easiest way to store this information would be to<br>
include it in the first 4 bytes. Instead of "META" they could then be<br>
e.g. "METZ" to indicate the content of the metatile is gzip encoded.<br>
This would allow things to be completely backwards compatible and not<br>
interfere with raster tiles served by mod_tile.<br>
<br>
If a bigger version change of the meta-tile format would be the best<br>
idea, are there any other changes that would be sensible to do at the<br>
same time?<br>
<br>
For example, one could potentially store the md5 sum of each tile in the<br>
metatile header. If tiles are in memory, I think calculating the md5 is<br>
at least partly the bottleneck in serving tiles. On the other hand, I am<br>
not sure if that really is any real concern, as I can get over 2 Gbit/s<br>
at 20000/s tiles out of my laptop in benchmarks. So I suspect in real<br>
world scenarios other elements of the system bottleneck long before the<br>
speed of mod_tile becomes an issue.<br>
<br>
Kai<br>
<br>
<br>
[1] <a href="https://github.com/mdaines/cover" target="_blank">https://github.com/mdaines/cover</a><br>
[2] <a href="https://github.com/kothic/kothic-js" target="_blank">https://github.com/kothic/kothic-js</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><br>
<br>
<br>
End of dev Digest, Vol 92, Issue 3<br>
**********************************<br>
</blockquote></div><br></div>