[Geomoose-users] WFS-T ideas
TC Haddad
tchaddad at gmail.com
Mon Apr 25 10:58:04 PDT 2016
Yes - Apache can prevent users from accessing apps with editing features
that they should not have access to, and column edit control can be at the
TinyOWS level, But items like pick-lists sound like database level controls
that would have to be custom integrated into your UI.
As for topology rules like connectivity, and roads vs lakes, PostGIS might
be able to help there, but you would need a way to gracefully handle
rejected contributions. Is there an example out there that does this well
in any app that you've seen?
On Mon, Apr 25, 2016 at 10:41 AM, James Klassen <klassen.js at gmail.com>
wrote:
> My (possibly outdated) experience with TinyOWS was it was all or nothing
> at the apache level.
>
> Nothing to control select/insert/update/delete per user or per layer and
> certainly not per column or per feature.
>
> Also no way to enforce other data consistency constraints (lines must be
> connected to something, roads can't run through lakes, value has to come
> from a list, etc.)
> On Apr 25, 2016 11:43, "TC Haddad" <tchaddad at gmail.com> wrote:
>
>
> Couldn't you handle login at the Apache level?
>
> TH
>
>
> On Monday, April 25, 2016, Brent Fraser <bfraser at geoanalytic.com> wrote:
>
>> Jim,
>>
>> Interesting ideas. I had considered views (I use them extensively with
>> the old GeoMOOSE editing) for other purposed like styling, but I didn't
>> want to push my luck with TinyOWS. It is implied in the TinyOWS doc that
>> it will work with views (I'll test that).
>>
>> The more bigger issue is security. With the old GeoMOOSE editing
>> mechanism, I handled security in the PHP. It checked the session to ensure
>> the user was logged in and issued the SQL if they were. I guess I'll need
>> to code some PHP to act as a proxy between TinyOWS and GeoMOOSE.
>>
>> Remind me how is WFS-T better? ;)
>>
>> Best Regards,
>> Brent Fraser
>>
>> On 4/25/2016 9:48 AM, Jim Klassen wrote:
>>
>>> An option for TinyOWS might be to do the attribute filtering in
>>> PostgreSQL with some combination of views/triggers/rules. You probably
>>> want to somehow enforce that clients can't view or update fields that
>>> they shouldn't.
>>>
>>> On 04/22/2016 01:34 PM, Brent Fraser wrote:
>>>
>>>> Tanya,
>>>>
>>>> Lots of wanderings. I ran across http://featureserver.org/ while
>>>> searching for a WFS-T server with more options for a data store
>>>> back-end (like Spatialite). Looks like support has died out though...
>>>>
>>>> Best Regards,
>>>> Brent Fraser
>>>> On 4/22/2016 12:06 PM, TC Haddad wrote:
>>>>
>>>>> Awesome,
>>>>>
>>>>> "exclude_items" was just what I was interested in. Thanks!
>>>>>
>>>>> Interesting topics all of this. I'm very interested in your WFS-T
>>>>> wanderings, even though I don't currently have a project to apply
>>>>> them to.
>>>>>
>>>>> thanks for continuing to prompt,
>>>>>
>>>>> Tanya
>>>>>
>>>>> On Fri, Apr 22, 2016 at 11:02 AM, Brent Fraser
>>>>> <bfraser at geoanalytic.com <mailto:bfraser at geoanalytic.com>> wrote:
>>>>>
>>>>> Tanya,
>>>>>
>>>>> There are a couple of things happening here with respect to
>>>>> attributes. As a GeoMOOSE implementer, I can limit the
>>>>> attributes in the Attribute Dialog by specifying only the ones I
>>>>> want to present to the user in the <mapsource> definition in the
>>>>> mapbook:
>>>>>
>>>>> <attribute name="geoid10" type="user" label="ID:"
>>>>> default-value="27999"/>
>>>>> <attribute name="namelsad10" type="user" label="Name:"/>
>>>>> <attribute name="classfp10" type="select" label=" Type:
>>>>> " default-value="C5">
>>>>> <option value="C1">C1</option>
>>>>> <option value="C5">C5</option>
>>>>> </attribute>
>>>>>
>>>>> even though there could be an additional 10 attribute fields in
>>>>> the database for that feature type, the user will never see
>>>>> them. All good.
>>>>>
>>>>> The other thing is a little odd. In my Iceberg application I
>>>>> have a "created_time" that gets automatically populated by the
>>>>> Postgres database engine:
>>>>>
>>>>> created_time timestamp with time zone DEFAULT now(),
>>>>>
>>>>> In my testing, TinyOWS was generating an error regarding time
>>>>> formats, which was unexpected since I never listed the
>>>>> created_time attribute in the mapsource. It appears TinyOWS gets
>>>>> all the attributes by default. I was able to prevent this by
>>>>> adding a line in the TinyOWS config.xml:
>>>>>
>>>>>
>>>>> exclude_items="created_time,approved_time,deleted_time,obs_time"
>>>>>
>>>>>
>>>>> Best Regards,
>>>>> Brent Fraser
>>>>>
>>>>> On 4/22/2016 11:38 AM, TC Haddad wrote:
>>>>>
>>>>>> Hi Brent
>>>>>>
>>>>>> Just briefly skimming the TinyOWS config options:
>>>>>>
>>>>>> - XML:
>>>>>> http://mapserver.org/tinyows/configfile.html#tinyows-configfile
>>>>>> - Mapfile: http://mapserver.org/tinyows/mapfileconfig.html
>>>>>>
>>>>>> I don't see a place where you can confine editing to only a
>>>>>> specific few attributes. It seems like you make the layer
>>>>>> editable or not (where editing includes geometry and all
>>>>>> attributes).
>>>>>>
>>>>>> I don't know the WFS-T spec well enough to know if it is an
>>>>>> option in the spec that is just not implemented in TinyOWS, or
>>>>>> what. Interesting question, will try to look it up.
>>>>>>
>>>>>> But anyhow, circling back to GeoMoose, if we wanted to find a
>>>>>> way for a user to "hide" fields from editing, it might have to
>>>>>> be entirely on the GM side if not supported by TinyOWS.
>>>>>>
>>>>>> Tanya
>>>>>>
>>>>>> On Fri, Apr 22, 2016 at 10:11 AM, Brent Fraser
>>>>>> <bfraser at geoanalytic.com> wrote:
>>>>>>
>>>>>> Interesting stuff. What did the layout of your attributes
>>>>>> form end up looking like? What would we need to address in
>>>>>> GeoMOOSE to make it usable in a project like yours?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Best Regards,
>>>>>> Brent Fraser
>>>>>>
>>>>>> On 4/21/2016 11:43 PM, Raffaele Morelli wrote:
>>>>>>
>>>>>> On 21/04/16 at 05:21pm, Brent Fraser wrote:
>>>>>>
>>>>>> Hey all,
>>>>>>
>>>>>> I've been experimenting with Geomoose's WFS-T
>>>>>> (feature editing). Any
>>>>>> thoughts about allowing teh target of the attribute
>>>>>> editing to be a tab
>>>>>> instead of just a dialog?
>>>>>>
>>>>>> Recently I've been involved in a survey project,
>>>>>> basically I was asked
>>>>>> to allow ~4500 users to insert points on a map and fill
>>>>>> a form (attributes).
>>>>>>
>>>>>> Attributes form was "huge", ie ~15 select lists (with
>>>>>> multiple choice) and ~5 textbox, I
>>>>>> would have liked to use GeoMOOSE but WFT-T issues (those
>>>>>> recently pointed out to this ML)
>>>>>> and your point made me give up and switch to
>>>>>> Drupal+Openlayers.
>>>>>>
>>>>>> Must say I did not spent too much in digging into GM
>>>>>> code for that attribute thing
>>>>>> as my deadline was really close.
>>>>>>
>>>>>> Ciao
>>>>>> /r
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Geomoose-users mailing list
>>>>>> Geomoose-users at lists.osgeo.org
>>>>>> <mailto:Geomoose-users at lists.osgeo.org>
>>>>>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Geomoose-users mailing list
>>>> Geomoose-users at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>>>
>>> _______________________________________________
>>> Geomoose-users mailing list
>>> Geomoose-users at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>>
>>
>>
>> _______________________________________________
>> Geomoose-users mailing list
>> Geomoose-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-users/attachments/20160425/dfa1a205/attachment.html>
More information about the Geomoose-users
mailing list