+1
On Tue, Sep 14, 2010 at 11:06 PM, Justin Deoliveira
wrote:
> Hi all,
> During the last few works I have been working on initial GML 3.2 support in
> GeoServer. I am at a point where I would like to commit to the trunk. Here
> is the proposal.
> http://geoserver.org/display/GEOS/GSIP+50+-+GML
Looks like a great idea. Looking at the review they look like issues
worth addressing - particularly CITE testing and docs :-)
So, you can have a preliminary +1 once those issues are addressed.
One other question - and I may be behind the times here and its
already there - is there a hook in the
Generally, stricter is better in terms of maintenance - there is a
good reason they found it worthwhile to improve strictness in some
place.
+0 on that basis and not wasting the work.
Rob
On Tue, Oct 12, 2010 at 10:26 AM, Justin Deoliveira
wrote:
> Hi all,
> Recently i have come across a few e
+1
it would alos allow previewing the connection with the standard UI!
Rob
On Wed, Oct 13, 2010 at 6:50 PM, Andrea Aime
wrote:
> Hi,
> I was wondering, is there any way to make the app-schema store refer to
> an already configured GeoServer store instead of adding all in the info
> inline in th
Hi Eli,
this is great work, nicely described. Please attach the patch to a
JIRA task, and create those other JIRA tasks.
Previously I've done the same sort of thing using SLDs - each SLD can
have a filter and I stored a parameterised SLD - and parameterised WFS
templates for the same purpose, in
+0 (i havent had time to think about the approach, but support the concept),
On Thu, Oct 21, 2010 at 7:49 PM, Jody Garnett wrote:
> I tried to indicate my +1 last week. I am excited by the technical direction.
> Jody
>
>
> On Tue, Oct 19, 2010 at 11:54 PM, Justin Deoliveira
> wrote:
>> Hi all,
+1
On Tue, Oct 26, 2010 at 5:33 PM, Andrea Aime
wrote:
> On Tue, Oct 26, 2010 at 12:00 AM, Justin Deoliveira
> wrote:
>> Hi all,
>> Thanks to everyone for voting on the catalog/config refactor gsip. Now that
>> this is out of the way i would like to add the new dbconfig stuff as a
>> community m
This is a good idea IMHO - particularly if the process of tagging and
assigning release identifiers can be automated - automation requires
clarity of the process, which is a good thing too :-)
Andrea's experience about whats actually most reliable is really
important to learn from.
Two suggestion
> This still assumes you can plan ahead a release by two weeks.
> I'm not normally in such conditions, I can have the occasional slow day,
> or the boring weekend, but I cannot foresee when that will happen.
> What I'd like to see is the possibility to cut a release with minimal
> warning instead.
Welcome to _my_ nightmare :-)!
There is a lot, a LOT, of debate at the moment about optimal form of
identifiers - see the UK Location Strategy for example. EPSG as an
entity no longer exists - making things fun...
I think we can only cope by addressing the reality - the concept we
are identifying
+0 (reflecting just ignorance of the state of it, not any reservations)
Rob
On Mon, Nov 15, 2010 at 9:47 AM, Mark Leslie wrote:
> +1 !
>
> On 13 November 2010 08:56, Andrea Aime wrote:
>> Hi,
>> here is the latest GSIP for your voting pleasure:
>> http://geoserver.org/display/GEOS/GSIP+55+-+Pro
App-schema allows clients to use style sheets to deal with responses.
(Because its a known schema, a stylesheet can be published and used to
render it. I have build clients with catalogues of stylesheets for
each feature type - and no way would it be worth bother with ad-hoc
flat schemas). We buil
Thu, Nov 18, 2010 at 7:00 AM, Rob Atkinson
> wrote:
>> App-schema allows clients to use style sheets to deal with responses.
>> (Because its a known schema, a stylesheet can be published and used to
>> render it. I have build clients with catalogues of stylesheets for
>
"The optional numberOfFeatures attribute is used to indicate the
number of features that are in the response document."
Why not just ignore it by default (maybe a configuration flag to force it).
Does anyone know of any clients that rely on it (even though its optional?)
Rob
On Tue, Nov 23, 201
+1 - welcome back!
On Thu, Nov 25, 2010 at 2:07 PM, Ben Caradoc-Davies
wrote:
> I am pleased to nominate Gabriel Roldán for the GeoServer Project
> Steering Committee.
>
> Gabriel is a former PSC member whose reputation precedes him; Gabriel is
> a prolific committer [1], maintainer of ArcSDE plu
+1
it seems that we've captured one concern when dealing with another -
rest and configuration management are independent concepts, and we've
either applied policy to REST, where we want to apply it to config, or
we've named a config interface after the protocol. Worth fixing at
some stage - but i
+1 on this strategy
its perfectly natural to have "levels of conformance" - and at some
point someone will probably want to define limited functionality
profiles of these specs - so it should be possible to prioritise
improvements against such requirements if and when they emerge,
otherwise be dri
moral support, at the very least :-)
I'll forward it on to the OGC as well - and see if I can get a
response. There is an emerging discussion on HTTP protocol and
browser-friendliness...
Rob
On Sat, Dec 11, 2010 at 6:18 AM, Andrea Aime
wrote:
> Hi,
> tried implement the OWS 2.0 policy of retur
whether OWS can be considered
RESTful :-) (and the answer is of course no!)
good luck with the workarounds - its really working around I.E's
behaviour, which is frustrating on many levels.
Rob
On Sat, Dec 11, 2010 at 10:00 AM, Rob Atkinson wrote:
> moral support, at the very least :-)
>
>
looks like a good idea.
my first thought was how does this relate to GeoXACML - and I see you
have been thinking about this - is it possible to map out what
GeoXACML would require and how this proposal supports this? If I was
an expert in GeoXACML I'd do this myself - but I'd then be in the dark
a
+1 for option 1
I think your concerns are well justified, and only if someone had some
major funding milestone needing a RC today should we consider it.
Rob
On Fri, Jan 7, 2011 at 11:51 AM, Justin Deoliveira wrote:
> Hi all,
> As was discussed last week the plan is to start the RC1 release tomo
there will be interest from
the Spatial Information Services Stack project, (contributing the
app-schema support) in this as some of the funding comes from the
earth resources sector, and they have a lot of 3D data.
Regards
Rob Atkinson
On Wed, Jan 19, 2011 at 2:12 AM, Sjoerd Brandsma wrote:
>
+1.
No doubt it will raise the ante for describing the content of layers
better - both structurally (schema) and the domain and range of each
element.
some interesting movement in OGC to make the capabilities more
modular, which is another necessary precursor to describing data well.
Rob
On Mon
+1 from me.
Although I'm somewhat on the outside these days I get a sense of a
more orderly and better communicated evolution with fewer nasty
suprises and fantastic levels of mutual support across teams and
geographic boundaries. Respect!
Rob
On Thu, May 26, 2011 at 2:52 AM, Justin Deoliveira
+1
sounds pretty cool.
It would be nice to allow a range and step size instead of just
discrete value list
maybe avalmin avalmax avalstep
or avalstep=start,end,stepsize
I also think you need an example of how CQL_filter would have an
avalue - i suspect it would need to be a parameter within a
Given the obvious focus and lead of the Met/ocean and climate
communities on interoperability, core capablities in time series
portrayals would be very welcome I expect.
Rob A
On Thu, Jul 28, 2011 at 5:38 PM, Andrea Aime
wrote:
> On Wed, Jul 27, 2011 at 11:33 PM, Gabriel Roldan wrote:
>> WRT t
+1 to both from me
On Tue, Mar 18, 2008 at 3:19 AM, Chris Holmes <[EMAIL PROTECTED]> wrote:
> I have two developers that I want to nominate for limited commit rights
> to GeoServer.
>
> The first is Ben Caradoc-Davies, who works with CSIRO, for commit rights
> to the community-schemas module in
Excellent analysis Andrea. I'd agree with all these points.
Couple of points to explore;
a) reusability of common components - things like file browsers etc
are often provided by the framework, but can we create additional
re-usable plugins easily - such as CRS choosers?
b) in the case of plug-i
>
> Can you make me an example of "getting the info from the optimal place
> in the optimal way"? Afaik with the current configuration API we have
> just one place to grab each information we need to build up a UI,
> and this sounds like a very good thing (TM) imho.
>
OK, for example, we speci
Is probably worth understanding these things rather than trying to
back out meaning from the current rather confused situation.
see: http://en.wikipedia.org/wiki/Namespace_%28computer_science%29
Namespaces therefore form a key part of the contract between the user
and the service - i.e. they are
I agree.
We can much more easily analyse the machine interface to make sure it
is self-consistent and that information is not redundantly managed,
than we can a UI. Getting the API working well should inform the UI
factoring.
In general, one wants info artefacts for the UI to come from
registries
FeatureAPI,
but for now you'll have to live with WFS 1.1
The Geoserver config should have sample queries using WFS 1.1 ...
Rob Atkinson
On Tue, Apr 22, 2008 at 4:48 PM, Andrea Aime <[EMAIL PROTECTED]> wrote:
> Mark Leslie ha scritto:
>
> > I'm getting a TransformerExc
Good stuff.
Gabriel may have further insights, but here's my perspective on what might
be worth considering:
1) No serious profiling work has been done on this build, and it wouldnt
suprise me if significant gains can be made
2) Fixes should target the trunk, so we'll need to re-run the profiling
WMS is not currently supported in this build., We decided to wait until the
trunk was ready and port to it rather than clone and hack the WMS module.
(AWDIP services are about data transfer, not visualisation), they need to be
judged against the requirements for this, so in fact blinding speed is
the tools each
development cycle.
Rob A
On Fri, May 16, 2008 at 4:08 PM, Stefan Hansen <[EMAIL PROTECTED]>
wrote:
> Rob Atkinson wrote:
>
> 3) The database seems to be hit twice per query, which may be a
>> significant overhead if the db side is slow
>>
>
> Tha
The plan I plan to plan (with the paymaster's consent) is:
1. Achieve basic WFS 1.1, GML 3.1 capabilities required, implementing test
cases.
2. Deploy to time-sensitive testbed activity
3. Port to trunk, and debug against test cases and WMS capability
4. Hopefully update deployments to include
While we are at it, I should note that date, timestamp, timestamp with TZ
handling inside the existing implementation is pretty weak. I have been able
to create overriding extensions that behave well enough to support filters
and encoding, but a systematic set of test cases in the encoding cases, a
ns, possibly geometryless will work for
you. The vast majority of geo-referenced business data is in multiple tables
with point locations, or references to named features. Geometryless was
designed to enable the former. Getting SQL-datastore extensions into the
core would enable them all.
Regards
7 and
trunk. At that point we hope to re-enable WMS support, for instance.
It would be helpful to know you requirements - what schema you are aiming
at, and how complex the features you need are, so we can factor those
requirements into our planning.
Regards
Rob Atkinson
CSIRO
On Wed, Jul 9,
Thanks for the review Jody,
my feedback is that I try to filter out actual voting requirements and act,
and look at proposals within my area of competence and interest, but its
very hard to follow the actual process.
Can we use JIRA perhaps to register the GSIP, so that PSC members are
automatica
II'll let you guys sort it out. Two meetings might work, or possibly more
targetted meetings around specific GSIPs?
Apropos of the GSIPs, I think we need to pull out the active voting
requirements from the bag of "being discussed" stuff, so that there is a
greater transparency.
Rob
On Wed, Jul 1
+1 from me too.
On 7/17/08, Jody Garnett <[EMAIL PROTECTED]> wrote:
>
> Seems all good on this end;
> +1
> There was some enthusiasm for cleaning up the code.
> Jody
>
> Jody Garnett wrote:
> > David can you update the GSIP page as these votes come in? We are
> > supposed to link to the several a
re permitted (SECURITY!)
> > (See GEOT-1930.)
> >
> > More and better support when this is merged onto trunk and into core.
> >
> > Credits go to Rob Atkinson for the concept, name, and advocating this
> > approach to users for about a year. :-)
> >
>
hmm - IMHO not having to get a WFS change request is starting small. Just
accepting that we can get the functionality working and work out how to
advertise it later (i.e. there isnt really much point advertising it if its
feature specific) seems to me a much lower bar. Getting the big picture
righ
Having lived through the debate not that long ago, I dont yet see a
compelling reason to change our conclusions: GeoServer trunk should
always follow GeoTools trunk, and any fixes to branches should be
ported forward to trunk. If we need a stable baseline badly enough,
then a new bracnh (gt 2.6) a
Perhaps the paradigm we are looking for is more like version control,
where incremental changes are made to a body, and when happy with a
complete set we tag the set.
It would be neat to be able to store and access components of
configurations in a version control system or other registry
infrstru
+1 from me too.
(and if we can abstract it to allow future use of version control in
the background we could one day exploit it to provide a revert
function)
RA
On Thu, Aug 7, 2008 at 9:51 AM, Jody Garnett <[EMAIL PROTECTED]> wrote:
> Justin Deoliveira wrote:
>> +1. The new configuration backen
our plan to the table at that point for
discussion. If this fits in with other decision making it might be
easier for all of us,
Regards
Rob Atkinson
On Sat, Aug 16, 2008 at 8:49 AM, Chris Holmes <[EMAIL PROTECTED]> wrote:
> No, you all should decide, and I guess OpenGeo is still decidi
+1 from me too. And I have no doubt he could be me at a football match.
Rob
On Fri, Aug 22, 2008 at 3:20 AM, Justin Deoliveira <[EMAIL PROTECTED]> wrote:
> +1 only if Simone can beat me in a foosball rematch. :)
>
> Andrea Aime wrote:
>> Hi,
>> as you know we have a vacant position in the PSC si
What about allowing the logging to be separated from the config?
Logging is a different issue than configuration for a production
system, and its very unusual not to have a separate location.
It would be nice to have a load location and a write location for the
config - this is the template idea y
tried to comment on the page but it threw an error...
here's my comment
Agree that current situation is sub-optimal. Ideally, IMHO,
documentation ought to be able to be generated easily within each
module and previewed by the module maintainer. If this step doesnt
require a build, but a build ac
+1
On 10/5/08, Simone Giannecchini <[EMAIL PROTECTED]> wrote:
> +1
>
> On Mon, Sep 29, 2008 at 9:27 AM, Jody Garnett <[EMAIL PROTECTED]> wrote:
> > +1 here.
> >
> > Jody
> > Justin Deoliveira wrote:
> >> Hi all,
> >>
> >> So I think all the feedback has been gathered and handled for the
> >> brand
> So what I'd like to see is a set of incremental (small) patches
> that do unlock the usage of DataAccess and complex features
> one bit at a time, going up from the catalog unto the
> output producers.
> It would be nice if each patch could be reviewed and then
> committed.
> I also expect to see
not sure if this is a formal vote, but +1 from me too.
Ideally the documentation could be updated, and the UI for configuring
the old datastores should provide a convenient alternative link to UI
for the new one.
How hard would it be to apply the old store config to the new one?
Rob A
On Mon,
Hi Justin,
I did an experiment and hacked xsd-gml3 to use a gml3.2 test case, and
it looks like the bindings for gml 3.1.1 are basically re-usable for
gml3.2 support. I know we'll need a new binding (gml:identifier,
basically a gml:name)
it seems that its the tests which are most heavily bound to
a different package. W e can
> then create a new GMLConfiguration class for the new bindings. I think will
> suffice with a minimum amount of "clutter".
>
> So the question is how do we proceed with implementing the new bindings. You
> said alot of the 3.1 bindings can be reused, w
Every day we seem to build all modules from scratch - regardless of
whether they have changed - which seems to mean you have to either do
a full mvn install orust as bad, a full download every day you make a
change.
In particular, you cant just build a module you care about and then be
alerted it
When you say "its not an option" because of "those who pay the bills",
you sound like you are either declaring post-facto or proposing a move
to a "Cathedral" model of OS. GeoTools/GeoServer has previously prided
itself as being a "Bazaar".
If this is not the intention, then a better mechanism nee
project policy for a single release. But lesson learned, the
> community has spoken. Won't make the mistake again.
>
> -Justin
>
> Rob Atkinson wrote:
>>
>> When you say "its not an option" because of "those who pay the bills",
>> you sound like
>>> Cool. Let's try to come up with perhaps a specific roadmap / pitch to
>>> put on the GeoServer site, so we can point people at a plan, that they can
>>> help accelerate with funding. I'll try to put some time in to this next
>>> week, perhaps we can try to pass it around on a wiki site. I th
ant efficiently handle with mappings
Rob
On Thu, Nov 27, 2008 at 7:52 PM, Andrea Aime <[EMAIL PROTECTED]> wrote:
> Rob Atkinson ha scritto:
>>>>>
>>>>> Cool. Let's try to come up with perhaps a specific roadmap / pitch to
>>>>> put on
robustness of the core solution.
Rob
On Fri, Nov 28, 2008 at 9:50 PM, Andrea Aime <[EMAIL PROTECTED]> wrote:
> Rob Atkinson ha scritto:
>
> Hem Rob, can you please keep the ml cc'ed?
>
>> Thanks for the clarifications about your intentions. We'll liaise if
>>
I like the work Justin has done on the Roadmap process,
I think our core interest will lie with the transition to the 2.0
series, when Ben gets back we'll confer and try to provide details.
Timing is still fairly challenging to predict.
So, you have a default +0 from me to pragmatic inclusions of
-2378
I'd be interested in seeing what else is targeted for 2.0 in the
emerging roadmap, and what it's big announcement is. Meeting basic SDI
requirements seems a pretty good reason, and we cant begin to claim
this until we land these issues.
Rob Atkinson
On Wed, Dec 10, 2008 at 1:49
he highest
> priority. Our tech is kicking major ass, we need to make it more obvious to
> people how to use it. The RestConfig stuff in particular will need a lot of
> documentation and examples and sample scripts. But we've known for awhile
> that most of the docs could use some
Way cool.
I think that having some separation of concerns will help us
enourmously. We could haemorrahge infinite effort into viewing demos
and SLD stylers and simply end up being harder to integrate with other
technologies that have similar solutions.
One day I hope a SLD wizard would be driven
I met these guys in Reading UK a couiple of weeks ago...
note its the complex feature support (for OGC Observations and
Measurments) which is the issue for WFS - they have noted its on the
road map (and I didnt even talk to them beforehand!).
FYI My group will be collaborating with the meteorolog
I dont know how many times I've said this, in many contexts - content
management as well as spatial - but if we rely on getting people who
care about the content working with technology then there is a
problem.
Glossy UIs are not a bad thing by any means, but only make them
believe for a short tim
or through it?
Merry Christmas
Rob
On Wed, Dec 24, 2008 at 6:49 PM, Andrea Aime wrote:
> Ben Caradoc-Davies ha scritto:
>>
>> Andrea Aime wrote:
>>>
>>> Rob Atkinson ha scritto:
>>>>
>>>> Glossy UIs are not a bad thing by any means, but only
Well done Justin
+1 in principle, with the following comments
1) I think the tone of the introduction could be a little more
positive, its really about supporting each other
2) A useful perspective might be about managing paid project risks
3) I think there is an over-emphasis on all proposals
> Hmmm... I don't think the inside-out approach was the cause of the
> problem. This is just my opinion but the lack of funding and failure to
> engage the core developer community is what led to these forks not going
> anywhere.
Sounds like its worth being aware that in the last round of effort
t
And in the meantime it sounds like Ben will have completed a local
spike and be ready with the patch :-)
If the GSIP process takes so long, maybe we should have a single one
"fix everything" - seriously the effort that goes into breaking down
the big picture into small, regression testable changes
Thanks for this work Justin,
a couple of notes,
making WMS work with a DataAccess is on the radar, keeping it working
with DataStore is the obvious short term requirement.
so, do the inbuilt unit tests or the CITE tests contain a sufficient
regression test for WMS? I got the impression it was a
Again, we have a little bit of a corner case perhaps, with commit
access to someone who works as part of a team, but isnt the primary
point of contact with the community.
I know its a lot easier to interact within a team through a software
development process that uses a commit/review cycle than r
+1
Q. Has anyone looked at CSV/Excel import via transactions ? (this
actually came up in a conversation today!)
Rob
On Wed, Feb 11, 2009 at 4:59 AM, Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>
>>> - feature id is never included in the output. Shall we include it?
>>>Or add an optio
Great work Chris!
This is a fantastic resource.
Its also been useful for me just to understand some of the threads
floating around.
thanks a lot
Rob
On Tue, Feb 17, 2009 at 9:04 AM, Chris Holmes wrote:
> Hey all, so I used to maintain a page that was called 'roadmap', with
> short, medium a
l. FYI I'm currently leading research projects
looking at ways to make richer structured metadata about data content
visible. The "value" metadata discussed here will be vital for
finding data in a large (well-populated) SDI environment. I'd
t lack of good metadata should not prevent anyone
> from putting real data out there.
>
Would totally agree with this. "Good" is very subjective, so get the
data out while you work out what is good in different contexts!
Rob
> Chris
>
>>
>> >
> * 1.7.x into bug fixing mode
>
> As feature development winds down on 1.7.x what do people think about
> putting 1.7.x into bug-fix only mode? The motivation is to focus on 2.x
> and the features that have been brewing there for probably too long. We
> will of course still put out regular release
do it in Geoserver - Ben has been doing som work on
setting up test cases for Geoserver, but I dont think we have a easy
to use test configuration you can tweak yet - but this will be a
priority th
Rob Atkinson
On Thu, Mar 5, 2009 at 2:04 AM, odi wrote:
> Hi,
> I've heard that complex
d of clients. It should be possible to "make this up" during
FeatureType configuration, or use one extracted from the definition of
the FeatureType (the application schema case). Its not clear to me if
this is an issue - probably an implementation issue, not a directory
structure i
On Wed, Mar 18, 2009 at 11:51 AM, Jody Garnett wrote:
> Ah you miss understand me; we are discovery the services in code form;
> as such we do not need a folder to straighten all the individual
> service files out.
>
> I expected to see a service/ folder but it is not strictly needed.
>
I wasnt c
s one :).
>
Manually defining namespaces during configuration is a corner case in
the long run. These will always be defined in application schemas, or
can be generated automatically without user configuration if they have
no external meaning. So, just want to avoid putting too much effort
int
Oh dear
doesnt an oversimplification always cause headaches..
A couple of observations that have not yet been made...
1) A Layer is not the same as a FeatureType, semantically. Hence
assuming they are the same will always cause a problem. For example, a
RoadNetowrk may consist of roads, bridges,
>
> Last time I checked application-schema datastore was read only?
Yes it is, but we should discuss this as part of the next steps strategy work.
> And GeoServer must do WFS-T. What I really want is something that
> allows me to rename attributes and map types on simple features
> without:
> 1)
Hi
I've been waiting for the basic app-schema capabilities to come on
line so I can test them, after that my priority will be working out
what to do with geomtryless - which relies on sql-datastore.
I'm wondering whether I will be able to completely deprecate the
geomtryless module by either:
a)
Supporting this would be a very good thing, and well worth the investment.
One slight addition to the analysis: a lot of services are exposed via
firewalls and proxies - and these set-ups are often imposed across
large swathes of government by (practically) immutable and poorly
designed service co
Will it help if we aim for CITE compliance with 2.0, using the
app-schemas stuff.?
For people who will care about CITE, they are probably going to care
about app-schema support as well (cf. INSPIRE).
IMHO we could afford to let CITE conformance slide for pre 2.0
versions - in much the same way as
problems do arise, that seem to
be hard to resolve, you can always back it out in a second cut.
The unit tests for app-schema could be disabled if the build time is
an issue, since this beta is not about testing the app-schema
functionality yet.
Regards
Rob Atkinson
On Fri, May 22, 2009 at 1:22 AM
for beta1,
but they obviously would be for beta2 so thanks for laying it out.
Sorry about the late response to the roadmap - I only got something
running yesterday to give me confidence it would be worth aiming at
this round of betas.
R
On Fri, May 22, 2009 at 5:00 PM, Andrea Aime wrote:
>
well done Andrea.
Your ideas about which formats they apply to seems to reflect a
variety of different reasons for doing this work - illustrating
perhaps how important it is.
These reasons include:
1) making sure the server is robust - doesnt fail with OOM or
something and deliver the wrong thin
er vs Geology). We
are getting good support from the OpenGeo folks, and are actively
working towards trying to have a app-schema available as a core
capability in standard Geoserver releases from 2.0 on.
regards
Rob Atkinson
On Tue, Jun 9, 2009 at 10:25 PM, Just van den
Broecke wrote:
> Hi
Thinking out aloud...
what if we have the same feature type being delivered by multiple
stores - for example a common gazetteer view of the different feature
types. Or sometimes we have several sub-types, and we want to provide
a single view using a supertype.
This situation does occur in practi
well, for a start its great to see the issue being debated before
finalisation of code :-)
I'm not over the intricacies of the beast to be honest, just providing
a "sanity check".
One thing I'd point out - namespaces do not exist to disambiguate the
feature type on the server - they exist to disa
Been chatting with Jody, Justin, Gabriel and a bunch of users - we had
an idea which might be relevant here...
Role-based wizards - this would address the concerns here in two ways:
1) you show the options most relevant to the role of the user -
service deployer vs system admin vs developer vs co
+1 from me
On Tue, Jun 30, 2009 at 4:12 AM, Andrea Aime wrote:
> Hi all,
> one of the points raised quite often at the Bolsena code
> sprint was that GeoServer is not part of OSGEO, and the
> thing is seen as odd and/or harmful for both entities.
>
> That is, people ask why GeoServer is not part o
+1
but I'd also caution that we need to understand the workflow and
objects before committing. Justin and I had quite a long and
productive conversation in Perth about possible workflows - and how
these could be optimised for different roles (the service manager as
opposed to the data specialist
the term I have been using is 'service profile' - i.e. how a set of
users expect a service to behave
Context matches the OGC generalisation of a WMS context. It sort of
relates more to an invocation than a configuration though IMHO
so, if you take the context to be the user-centric viewpoint of
c
agreed.
it would be good to tag discussions eg [Roadmap] so that it is easier
to pay attention, likewise GSIP stuff is usually well tagged, but you
still need to pay attention quite carefully.
Rob
On Mon, Jul 6, 2009 at 9:00 PM, Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> Hi all,
>>
>>
Sounds like a good idea
do we have a list of the "legacy" modules - are you talking
specifically about the old UI, or a broader cleanup?
Rob
On Tue, Jul 7, 2009 at 9:37 AM, Justin Deoliveira wrote:
> +1, less dependencies yay!!
>
> Andrea Aime wrote:
>> Hi all,
>> I was wondering if it's a good
1 - 100 of 152 matches
Mail list logo
