Role of StaticProvider

[zarov]

I was questioning myself about the utility of the StaticProvider StaticSource

I feel the title is really misleading, as it loads a JSON and not images directly. I propose to move it to another provider (what name ?), and write a new StaticProvider, with two simple methods, the preprocessDataLayer being almost empty, and the executeCommand only doing a simple fetch of the wanted resources, given the url passed.

WDYT ?

[elemoine]

StaticProvider doesn't sound as a very good name to me either. It looks to me that this provider is quite specific to panorama images. No? Would renaming it to PanoramaImagesProvider make sense?

[autra]

It looks to me that this provider is quite specific to panorama images

No it is not. We used it quite often in our projects. A lot of people have simple images for their maps, either of their building or of part of a city. Being able to place them easily (ie without a geoserver) is a very good time-saver. To elaborate, often these images are between 10-300mb, so we use gdal to create some tiles (either with several levels or just a "partition") and we generate a json with these metadata

That being said:

• the name may be better, probably (do you have a proposal?)
• maybe we can find something more... standard to achieve the same functionality? Does this exist? There is the gdal mini driver xml format for instance, but I'm not sure it can achieve the same functionality (here each images can be of arbitrary size and position).

As for your new static provider @zarov: how would you get metadatas about the images?

[autra]

AFAIK the name "Static" is in opposition to "dynamic from a geoserver/database/etc...". It's "static" in the sense "static files", like when a webserver serves a directory for instance.

[elemoine]

@autra ok thanks for the explanations, they make sense. No suggestion for a better name for now…

[zarov]

Thanks for the explanation ! As for the metadata, I was thinking that this provider shouldn't be limited to only images. I concede that the true objective I have in mind is ditching RasterProvider, and use the static one to have something like static -> gpxparsing/geojsonparsing/etc -> texture/mesh.

Or if we want to keep the current static provider, as it seems to make sense to me now, I see the following :

• keep StaticProvider, but grow it to have something else than images to load (like pbf for vector tiles for example), and complete the documentation ;)
• have the FileProvider, as introduced in FileProvider #705
• remove the RasterProvider to let FileProvider do the work

[mbredif]

Name : If I understand well the use case, 'Static' is more about your usage of it and is not intrinsic to what it does : to the extreme, you could have the json be generated on the fly by a REST API on top of some database for instance.
What about ImageCollectionProvider or ImagesProvider ?

Standard : As for a standard, the json file could be replaced by a geojson where the feature is the footprint and the properties gives the image url and the projection parameters

have the FileProvider, as introduced in #705, remove the RasterProvider to let FileProvider do the work

RasterProvider -> FileProvider : Sure ! At first sight, what needs to be done is :

• allow the initialization of the FileProvider by url rather than by a fileblob
• check the layer.type to switch between the conversion to an object3d (current implementation, with a convert function defaulting to Feature2Mesh.convert) and the conversion to textures for imagery layers (as done in the RasterProvider )

[autra]

RasterProvider -> FileProvider : Sure ! At first sight, what needs to be done is :

I don't see the link between RasterProvider (that get resources from an url) and FileProvider, that deals with javascript's File api.

allow the initialization of the FileProvider by url rather than by a fileblob

So it's not a file provider anymore. A provider that gets something from an url is just... Fetcher. Did I miss something?

[mbredif]

I was just proposing a shorthand for something like fetch(url).then(response => FileProvider(response.blob())).
Would you rather have a separate URLProvider that fetches a url and then do exactly the same thing as FileProvider on the resulting blob ?

I don't see the link between RasterProvider (that get resources from an url) and FileProvider, that deals with javascript's File api.

RasterProvider :

• downloads a file
• parses it (with hard coded parsers)
• transform it to textures to make it an imagery layer

FileProvider

• is given a File (I propose to alternatively download the file)
• parses it, with any user specified parser, or with the most suitable parser from the parser registry feat(parsers) Parser registry #723
• transform it to an object3d (I propose to transform it to textures instead if the layer type is not "geometry")

Is it now clearer that FileProvider would be a generalization of RasterProvider ?

[autra]

keep StaticProvider, but grow it to have something else than images to load (like pbf for vector tiles for example), and complete the documentation ;)

A provider is linked to one protocol in iTowns currently (and I'd like to keep it that way). StaticProvider defines its own custom protocol (which may not be very ideal, I agree). FileProvider also relies on one "protocol", which is just an instance of File. This may be another reason to first split Providers into sources, parsers and sinks (that produces Object3D, textures etc...) ? I think everything would be clearer then.

But yeah, StaticProvider is not about getting images, it's about a metadata json format (which is custom and proprietary, we might want to change that), a protocol actually. So it could deal with other things.

I was just proposing a shorthand for something like fetch(url).then(response => FileProvider(response.blob())).

Ok I see

Would you rather have a separate URLProvider that fetches a url and then do exactly the same thing as FileProvider on the resulting blob ?

It's not yet clear where and how network requests should be made. Even for simple fetch like this, we may want them to be scheduled and cached too. That implies that most of this logic will be in a core part of iTowns (Scheduler?) and URLProvider may be completely useless... So in short, the blob/xml/json etc... would be provided by the Scheduler (or equivalent).

Is it now clearer that FileProvider would be a generalization of RasterProvider ?

Actually, the way you describe it, FileProvider would now be something that get an url and transform it into an object displayable by iTowns. So FileProvider would be a generalization of half iTowns, not only StaticProvider ;-)

That's why I think this approach won't work in practice. I'm pretty sure what you describe as FileProvider (for the url case) should not be a provider and be in Scheduler or in other part of the core instead.

In short:

• let's not try to over generalize FileProvider, we risk to want to make everything go through it. Let's first scope its responsibility: deal with File objects.
• Imho, the very concept of a URLProvider is useless...
• actually, separating providers into sources (about protocols), parsers (about data format) and sink (about generating stuff displayable by iTowns) should probably be the first step.
• But I'm not even sure about all of these, and as a more meta remark: this discussion is a near-perfect example of why it is very quickly useless to discuss about code without code... :-D