<div dir="auto"><div>I see your point Vincent. I'm not planning to implement it and I don't have a strong opinion on the right design. From a user point of view it doesn't mske much difference either. So, no problem to converge :)<div dir="auto">I agree also on I3S being an Esri oriented standard (as it's been for GeoPackage, or KML for Google). Well the same could be said for 3D Tiles / gtTF and AGI, don't you think? Same as before, I totally respect the choices of who's putting resources on concrete development. It's just to share thoughts and opinions.</div><div dir="auto"><br></div><div dir="auto">giovanni</div><br><div class="gmail_extra"><br><div class="gmail_quote">Il 13 nov 2017 2:49 PM, "Vincent Picavet (ml)" <<a href="mailto:vincent.ml@oslandia.com">vincent.ml@oslandia.com</a>> ha scritto:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<div class="quoted-text"><br>
On 09/11/2017 16:49, G. Allegri wrote:<br>
> Hi Vincent,<br>
> I agree tiled static data can, and should, be served as static content<br>
> but what I meant was having something like Tilestache, GeoWebCache,<br>
> MapCache, etc.. They're meant to render and cache on the fly, or<br>
> preseeding the tileset.<br>
><br>
> My question raised from the fact that QGIS 3D renderer could be a common<br>
> base to produce terrain meshes (a la Cesium) and 3D tiles, both for the<br>
> desktop 3D viewer and for a cached tileset to be served through HTTP.<br>
<br>
</div>I would rather have a dedicated terrain mesh generator first, which<br>
could be embedded in QGIS 3D later on. Generating a terrain mesh is a<br>
data processing action, not a rendering one. We should tackle the<br>
problem in this order, or we will end up with code less efficient and<br>
less generic.<br>
<div class="quoted-text"><br>
> QgsServer could use the same code base to populate the cache, but this<br>
> doesn't prevent having a Processing tool (ore whatever) doing the work<br>
> in advance.<br>
<br>
</div>I think we agree on the general issue, but have a different point of<br>
view on the design process. We should converge at some point :-)<br>
<div class="quoted-text"><br>
> You're working with gltf. What about OGC I3S?<br>
<br>
</div>I3S is, like other examples, a standard pushed by ESRI for ESRI<br>
products. It has been designed by ESRI and pushed forward to OGC<br>
community standard in a desire not to adopt 3D tiles.<br>
I do not say that I3S is a bad technical standard. But it is just<br>
another effort from ESRI to favor its own specific formats instead of<br>
collaborating on a real "community" standard.<br>
<br>
It is therefore not a strong incentive to dedicate efforts for an<br>
opensource implementation.<br>
If there was funding for it, we could implement it too, as the<br>
specifications are open. But priority goes to 3DTiles as far as we are<br>
concerned.<br>
<br>
Regards,<br>
Vincent<br>
<div class="quoted-text"><br>
<br>
<br>
<br>
><br>
> giovanni<br>
><br>
> Il 9 nov 2017 16:29, "Vincent Picavet (ml)" <<a href="mailto:vincent.ml@oslandia.com">vincent.ml@oslandia.com</a><br>
</div>> <mailto:<a href="mailto:vincent.ml@oslandia.com">vincent.ml@oslandia.<wbr>com</a>>> ha scritto:<br>
<div class="elided-text">><br>
>     Hello,<br>
><br>
>     On 03/11/2017 21:04, G. Allegri wrote:<br>
>     > What if we had a QgsServer service dedicates to serving 3d tiles for<br>
>     > Cesium or iTowns?<br>
>     > Is anybody working on this?<br>
><br>
>     At Oslandia, we work on 3D topics a lot, and 3d tiles in particular. We<br>
>     are implementing 3D Tiles support in iTowns, and several components to<br>
>     serve this format as webservices.<br>
><br>
>     E.g. :<br>
>     - <a href="https://github.com/Oslandia/building-server" rel="noreferrer" target="_blank">https://github.com/Oslandia/<wbr>building-server</a><br>
>     <<a href="https://github.com/Oslandia/building-server" rel="noreferrer" target="_blank">https://github.com/Oslandia/<wbr>building-server</a>><br>
>     - <a href="https://github.com/Oslandia/lopocs" rel="noreferrer" target="_blank">https://github.com/Oslandia/<wbr>lopocs</a><br>
>     <<a href="https://github.com/Oslandia/lopocs" rel="noreferrer" target="_blank">https://github.com/Oslandia/<wbr>lopocs</a>><br>
><br>
>     I do not think having QGIS Server serving 3D tiles is a really good<br>
>     idea.<br>
><br>
>     First, 3D tiles is a format ( and protocol) to serve tiles of objects in<br>
>     a mostly static way. Therefore, what would be interesting is for QGIS to<br>
>     have a way to export data as 3d Tiles. These tiles can then be served<br>
>     with a simple HTTP server, no need for a QGIS Server component.<br>
><br>
>     Moreover, there are a lot of use cases where we want to serve 3D Tiles<br>
>     without using QGIS at all. Component-oriented architecture is better<br>
>     than monolithic software.<br>
><br>
>     What I see as best approach would be to mutualize as much code as<br>
>     possible regarding 3D tiles in py3dtiles :<br>
>     <a href="https://github.com/Oslandia/py3dtiles" rel="noreferrer" target="_blank">https://github.com/Oslandia/<wbr>py3dtiles</a><br>
>     <<a href="https://github.com/Oslandia/py3dtiles" rel="noreferrer" target="_blank">https://github.com/Oslandia/<wbr>py3dtiles</a>><br>
><br>
>     Using this module, we can write a 3dtile exporter, as a Processing<br>
>     module for example. We already have some draft code to do that for some<br>
>     data sets.<br>
>     Then, we could have an independant 3D tiles server reusing py3dtiles, or<br>
>     integrate this as QGIS Server module if we want.<br>
><br>
>     We would be happy to work on these subjects and share our experience on<br>
>     all 3D-related topics. Funding is also very welcome.<br>
><br>
>     But for now, I think we should focus on releasing QGIS3 in a usable<br>
>     state. We have waited for too long, and there is still work to achieve<br>
>     to stabilize the release.<br>
><br>
>     3D features can wait a bit more, even if call for interest, needs,<br>
>     funding and collaboration is welcome.<br>
><br>
>     Best regards,<br>
>     Vincent<br>
>     ______________________________<wbr>_________________<br>
>     QGIS-Developer mailing list<br>
</div>>     <a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a> <mailto:<a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.<wbr>osgeo.org</a>><br>
<div class="quoted-text">>     List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
>     <<a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a>><br>
>     Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
</div>>     <<a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a>><br>
<div class="elided-text">><br>
><br>
<br>
______________________________<wbr>_________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a></div></blockquote></div><br></div></div></div>