Hi Andrea,
On Mon, Feb 16, 2015 at 11:34 AM, Andrea Aime <[email protected]>
wrote:
> On Mon, Feb 16, 2015 at 6:47 PM, Andrea Aime <[email protected]
> > wrote:
>
>>
>> Doc doc... oh!
>>
>> https://github.com/geoserver/geoserver/tree/master/src/extension/importer/doc
>>
>> Did not see this one :-)
>> Interesting, I'll see if/how I can merge that into our docs
>>
>
I only realized the other day when you asked that these don't get included
into the doc build.
>
> Ok, so a few questions if I may.
>
> When creating a new import with proposed id with PUT, the code says:
> *"Create import with proposed id <importId>. If the proposed id is ahead
> of the current (next) id, the current id will be advanced. If the proposed
> id is less than or equal to the current id, the current will be used. This
> allows an external system to dictate the id management."*
>
> Soo... basically the id will be accepted only if it is greater than the
> current id, and the current will be updated to it, right?
>
Right.
> Besides that, one thing standing out is that the rst version of the doc
> says tasks has items, whilst the markdown
> one says tasks has layers, directories, files, but no items (and also
> cites the transforms, nice)
>
> Looking at the rest mappings declared in the applicationContext.xml it
> looks like items are not there, but layers
> are, so the API reference table in the rst document needs to be updated
>
I cannot recall how we ended up w/ two docs (Justin?) but the `item`
concept is now removed.
> One thing that I was wondering is, is it not possible to just POST the
> whole json/xml tree describing
> the import, its tasks, it transforms and whatnot in a single shot? Say for
> example that the upload
> (maybe large) was managed out of band with a different tool (FTP,
> resumable/chunked HTTP),
> I see no reason for making all this little calls to stand up a complex
> import.
>
I believe it's possible but have not tried.
Am I missing something?
>
The API is complex, agreed. As for the little calls, performance wise, they
are generally not noticeable. Usability wise, annoying, yes.
The idea was/is to support an interactive workflow:
user: here's my data...
gs: ok, I see you've given me 3 shapefiles, one with a bad/missing
projection and something I don't recognize/support
user: ok, ignore that other thing and use 4326 for that bad shapefile
user: now that I see my 'time' attribute is actually encoded as text,
convert that to a date
user: oh yeah, and import that 1st shapefile into the database but call it
something else and create an index on that attribute
...
If you know what you want to do ahead of time, this should ideally be
supported as well.
There was initially more 'post' import functionality present at one point
(layer configuration, etc.) but this seems like it belongs in the standard
catalog API.
Hope that explains some.
--
Ian Schneider
Software Engineer | Boundless <http://boundlessgeo.com>
[email protected]
1-877-673-6436
@boundlessgeo <http://twitter.com/boundlessgeo/>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
