[Potlatch-dev] P2, snapshot-server, imports, vector layers and more

[Paul Norman]

> From: Richard Fairhurst [mailto:richard at systemeD.net]
> Subject: Re: [Potlatch-dev] P2, snapshot-server, imports, vector layers
> 
> > [...]
> > I must admit I have not verified if this would require changes to P2.
> > It's possible that P2 would work fine if snapshot-server returned
> negative IDs.
> 
> I've not tested it but I'm 99% sure it would. Happy to test if you set
> up an instance somewhere which serves negative ids!

I believe I could serve the data from apache easily enough to test. It'd
return the entire dataset as a response to a map? Query but for testing with
a small dataset that shouldn't be an issue.

Deploying the P2 instance is what I'll have problems with - are there any
guides on how to deploy P2 with a custom vectors.xml (or imagery.xml) with
minimal pain?

> > 2. Data layer exposure. To add a snapshot-server data layer to P2 you
> > have to deploy your own P2 instance. This severely limits exposure.
> > What makes it worse is that if I offer a data layer and deploy P2 and
> > someone else does the same, you can't use both at the same time.
> >
> > A way to add a snapshot-server layer by pointing it at a configuration
> > file (e.g. a json file) would be very useful.
> >
> > Better yet would also be a way to reveal data layers like imagery
> > layers are, based on bbox (or better yet, by polygon).
> 
> Ok. You can already specify bboxes in vectors.xml in the same way that
> you do in imagery.xml. So I guess the problems to address are:
> 
> 1. Make it easier for 'data providers' to make users aware of data
> layers 2. Provide easy UI for users to select data layers
> 
> For 1; we could continue with vectors.xml, and also provide a way to
> provide a URL in the embedding page/query string (much as you can with
> background imagery).

That would be good, but is one URL enough information or do you also need
the crossdomain.xml file location? I suppose you could take multiple fields.

> (It might be possible to do what JOSM does by putting the sources on a
> wiki page, rather than relying on a commit to the P2 repository, but I'm
> always a bit wary of people adding Google imagery etc. without us
> noticing. Any thoughts?)

The JOSM wiki page is moderately painful to edit. I'm not convinced it's a
good way. It would be nice if there was one imagery source list XML format
shared between JOSM and P2.

> For 2; we could add a new menu like the 'Background' one showing data
> layers in the current area.

I think long-term this is a good idea, but would require more data layers to
be available. Are there currently any running besides cyclestreets?

Another issue that impacts on this is the lack of support for polygon
bounds. There is a huge overlap between the Canada and lower-48 states US
bboxes.