Testing Kosmo 2.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0

Rahkonen Jukka
Hi,
 
I checked Geoserver version 2.1 rc2 on my own computer and deegree demo server at http://demo.deegree.org/deegree-wfs/services.  Both those are sending at least GetCapabilites response without having "charset=" in the headers.  Perhaps it is not very reliable to search the character encoding from WFS response headers.
 
-Jukka Rahkonen-

_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0

Sergio Baños Calvo
In reply to this post by Rahkonen Jukka
Hi,

No problem about the previous reply ;).

I think i didn't explain myself correctly: TinyOWS is sending the response body correctly formated in UTF-8, but the response headers, that I used to set the charset for the request body reader, aren't filled correctly and the http client API can't get the charset from it, using ISO-8859-1 as returned value (the default one).

Comparing the two headers retrieved, seems that the IDEE WFS is adding "charset=UTF-8" to the request.

TinyOWS response headers:

Date: Wed, 18 May 2011 13:18:31 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/xml; subtype=gml/3.1.1


IDEE WFS response headers:

Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 18 May 2011 13:22:54 GMT


Anyway, it solved with the change I commented ;).

Regards,

El 18/05/2011 15:07, Rahkonen Jukka escribió:
Hi,
 
Sorry for the reply a minute ago without any comments.
First, I would really like to test the new client when it is possible.
 
Second, I will need to check the response headers.  However, I can see the encoding in the response body if I send this request with my browser
 
The result I am getting back begins with
 
<?xml version='1.0' encoding='UTF-8'?>
<wfs:FeatureCollection
 xmlns:tows='http://www.tinyows.org/'
 xmlns:lv='http://latuviitta.fi/'
 xmlns:wfs='http://www.opengis.net/wfs'
 
Perhaps that encoding information could be utilised?
 
I believe that with TinyOWS it will be wrong to believe that the result set is using the same encoding than the request. TinyOWS tells about a configuration parameter
encoding : OptionalOutput encoding. Default is UTF-8. Others values could be ISO-8859-1 for instance.
 
Thus I believe that if I set encoding to ISO-8859-1 it will be so even if I make request with UTF-8
 
-Jukka Rahkonen-
 
 


Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 18. toukokuuta 2011 15:49
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Hi,

Good news about the open issue: the connector have been improved again and it works now as expected:

[Image removed]

The problem with your TinyOWS is that, although I request it to send me the response in UTF-8, the response header doesn't contain any info about the response charset used (I have tested other servers, like the IDEE WFS server - http://www.idee.es/IDEE-WFS/ogcwebservice? -, and it fills the header correctly) and the http client takes ISO-8859-1 by default. So I have had to force the response reader to use the charset as if the server would always response as requested, and I have manage it to work that way.

I hope to have an update for testing tomorrow, if you like to test yourself.

Regards,

El 18/05/2011 9:32, Sergio Baños Calvo escribió:
Good morning Jukka.

The current WFS connector was using the first feature schema to build the layer schema, so that's the reason for the behaviour you commented in your mail. I have made some modifications to it in order to use the FeatureType schema instead, filtering out those attributes that have been unselected by the user, and it works right now :).

Respect to the filter issue, it's also related with the problem when reading the response from the server: it's not reading properly the response (sending the request). I will keep working on it today.

Regards,

El 17/05/2011 15:25, Sergio Baños Calvo escribió:
Hi, Jukka.

The osm_point layer works like a charm when removing the "tags" field, as you pointed in your previous mail.

Respect of the WFS reader, Kosmo Desktop WFS connector is based in OpenJUMP Degree WFS plugin. I'll check this afternoon the behaviour you're talking about with the lastest connector to see if the behaviour is the same after all the changes I'm doing to it.

The filter seems to be sent incorrectly, I'll check this also.

Regards,

El 17/05/2011 15:18, Rahkonen Jukka escribió:
Hi,
 
Some remarks on the WFS:
- Kosmo is using about the same WFS reader than gvSIG, or?  If yes, Kosmo may have same troubles than gvSIG (tested with version 1.11.0).
 
- Check the attribute table in Kosmo after doing GetFeature
 
Compare it with the layer schema
 
The resultset contains empty values for attribute "text3" and obviously therefore gvSIG builds an attribute table without that attribute.  The correct way would be to read the schema, make an empty table as an template and populate it then from the captured GML.
 
Also, I was not able to filter the "municipalities" feature type with a filter "kunta_ni1"='Saarijärvi'.  "kuknta_ni1"='Helsinki' does work, thus the error must be related to a non-ASCII character "ä".
 
-Jukka Rahkonen-
 
 


Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 13. toukokuuta 2011 13:30
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Hi Jukka.

Seems that the server is sending the response correctly, so it's a problem in client side: I'll revise how the request response is read, seems that it's ignoring the charset and it's reading it incorrectly.

Regards,

El 13/05/2011 12:07, Rahkonen Jukka escribió:
Hi,

Great progress!  You are right, some characters do not look right. You can try to compare with this direct GetFeature

http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=municipalities&maxfeatures=1

Data comes from PostGIS and it is UTF8 there. Most common non-ASCII charaters are a-uml, o-uml and a-ring
"äöåÄÖÅ", if they now look OK even through this mail.

-Jukka-


-----Alkuperäinen viesti-----
Lähettäjä: [hidden email] puolesta: Sergio Baños Calvo
Lähetetty: pe 13.5.2011 13:02
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0
 
Hi Jukka.

I did some adjustments to the connector yesterday and I could manage to 
load the layers municipalities, osm_line and osm_polygon (the osm_point 
layer keeps giving me problems with some characters in the attributes 
when I request 1.000 or more features).

Here it's a capture of the layer "municipalities" loaded in Kosmo 
Desktop. Could you confirm me that the attribute data hasn't been 
correctly retrieved (seems that some of the characters hasn't been read 
correctly in the fields "suural_ni1", "suural_ni2", "avi_n1" and "avi_n2")?

tinyows_municipalities


Regards,

El 12/05/2011 15:33, Rahkonen Jukka escribió:
Hi,
There may well be data errors in my current feature types because the 
OpenStreetMap data do not always convert easily into simple features 
and GML.  I have corrected some most obvious issues like renaming 
attributes like addr:housenumber into addr_housenumber but I am not 
surprised if there are some errors left. I should really add some more 
conventional feature types into the service and include other types of 
attributes than just strings.
I look forward to get my hands on your development version.
-Jukka Rahkonen-

    ------------------------------------------------------------------------
    *Lähettäjä:* [hidden email]
    [[hidden email]] *Puolesta *Sergio Baños Calvo
    *Lähetetty:* 12. toukokuuta 2011 16:23
    *Vastaanottaja:* International Kosmo mailing list (english languaje)
    *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

    Hi again Jukka.

    No problem for Kosmo Desktop, it's processing the operations in
    both ways, so the POST url (the one that uses Kosmo Desktop for
    connecting to the server) is being taken correctly (in the current
    development version, that error is present at the 2.0 official
    version).

    I have made some more testings in your server instance and seems
    that the connector is not retrieving properly some of the features
    from the server (it's giving errors when parsing the response when
    requesting 1.000 features). I'll keep you informed about any advances.

    Regards,

    El 12/05/2011 15:08, Rahkonen Jukka escribió:
    Hi,
    I may have found something new today, it is about how TinyOWS is
    listing the URLs for GetFeature in http GET vs. POST.  I have
    asked about is from deegree and TinyOWS user lists.  I believe
    you should check it as well. TinyOWS is announcing the GET and
    POST URLs in two separate ows:DCP elements while deegree and
    Geoserver are listing them as a list in one DCP element. I
    suspect that because of this OpenJUMP WFS plugin and iGeoDesktop
    do not find the Post URL at all.
    This is from deegree WFS
    <ows:OperationsMetadata xmlns="http://www.opengis.net/ows">
    <ows:Operation xmlns="http://www.opengis.net/ows" name="GetFeature">
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Get xmlns="http://www.opengis.net/ows"
    xlink:href="http://demo.deegree.org:80/deegree-wfs/services?"
    xlink:type="simple"></ows:Get>
    <ows:Post xmlns="http://www.opengis.net/ows"
    xlink:href="http://demo.deegree.org:80/deegree-wfs/services"
    xlink:type="simple"></ows:Post>
    </ows:HTTP>
    </ows:DCP>
    </ows:Operation>

    This is from TinyOWS
    <ows:Operation xmlns="http://www.opengis.net/ows" name="GetFeature">
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Get xmlns="http://www.opengis.net/ows"
    xlink:href="http://188.64.1.61/cgi-bin/tinyows?"></ows:Get
    <http://188.64.1.61/cgi-bin/tinyows?%22%3E%3C/ows:Get>>
    </ows:HTTP>
    </ows:DCP>
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Post xmlns="http://www.opengis.net/ows"
    xlink:href="http://188.64.1.61/cgi-bin/tinyows"></ows:Post
    <http://188.64.1.61/cgi-bin/tinyows%22%3E%3C/ows:Post>>
    </ows:HTTP>
    </ows:DCP>
    -Jukka Rahkonen-


        ------------------------------------------------------------------------
        *Lähettäjä:* [hidden email]
        [[hidden email]] *Puolesta *Sergio Baños Calvo
        *Lähetetty:* 12. toukokuuta 2011 16:00
        *Vastaanottaja:* International Kosmo mailing list (english
        languaje)
        *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

        Hi Jukka.

        Thank you very much for your assistance.

        I did some modifications to the WFS connector the first time
        but I didn't manage to connect to your old TinyOWS instance.

        I have made some testing over your new TinyOWS server and,
        after some adjustments to the WFS connector, I have finally
        got some data from it. The clue about the problem was given
        for a post made by you at the TinyOWS list (in this case the
        TinyOWS server response wasn't an internal server error like
        the last time, but a wrong content-type header exception):

        http://lists.maptools.org/pipermail/tinyows-users/2010-September/000193.html

        I'll try to generate a development version for testing in the
        next few days.

        Regards,

        El 12/05/2011 12:51, Rahkonen Jukka escribió:
        Hi,
        I sent some observations about Kosmo as a WFS client fot the
        TinyOWS server two months ago. Now I have updated my TinyOWS
        server into version 1.0 rc1 which is supposed to pass all
        the CITE WFS tests for both WFS 1.0.0 and 1.1.0. 
        Unfortunately after this update Kosmo does not get any
        further than reading the GetCapabilities and
        DescribeFeatureType.
        If you happen to have some development versions about the
        WFS client available I would be happy to do some testing. My
        WFS server is also open for you and it is still found at
        http://188.64.1.61/cgi-bin/tinyows?
        Regards,
        -Jukka Rahkonen-
        ------------------------------------------------------------------------
        *Lähettäjä:* [hidden email]
        [[hidden email]] *Puolesta *Sergio Baños Calvo
        *Lähetetty:* 10. maaliskuuta 2011 13:14
        *Vastaanottaja:* International Kosmo mailing list (english
        languaje)
        *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

            Hi again Jukka.

            Yes, the GetCapabilities and DescribeFeatureType
            requests works ok, but the problema arises when the
            GetFeature request is sent: as you mention in your next
            mail, Kosmo Desktop uses POST to get the features, so
            may be this is the problem.

            There isn't any clue in the "500 - Internal server
            error" response to get what's happening, it should be in
            the server log but the client doesn't get any hint.

            I started to translate Kosmo into Finnish and I hope I
            will have somehow usable language file next week. Where
            can I send it when it is ready?
            Great :). You can send it to me directly to my personal
            mail and we add a new update to the download web page.
            I'll need also the label you like to add to the
            contributors page.

            Regards,

            El 10/03/2011 10:05, Rahkonen Jukka escribió:
            Hi, and thanks for the answers.
            Sergio Baños Calvo  wrote:

            > I have tested your service (btw, thanks for it :) )
            > and, after correcting some code in the WFS connector
            > about XML parameters reading, I get to an
            > "500 - Internal server error". Could you check if
            > the server is working ok?
            GetFeature works for me both with WFS 1.0.0 and 1.1.0
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100>
            and
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100>
            GetCapabilities look good, as well as DescribeFeatureType
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point>
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point>
            I started to translate Kosmo into Finnish and I hope I
            will have somehow usable language file next week. Where
            can I send it when it is ready?
            -Jukka Rahkonen-


            _______________________________________________
            Kosmo_int mailing list
            [hidden email]
            http://lists.saig.es/mailman/listinfo/kosmo_int
            -- 

            Sergio Baños Calvo

            Jefe de desarrollos
            Sistemas Abiertos de Información Geográfica, S.L. (SAIG
            S.L.)
            Tlfno. móvil: 685005960
            Tlfno. fijo: (+34) 954788876

            E-mail: [hidden email]


        _______________________________________________
        Kosmo_int mailing list
        [hidden email]
        http://lists.saig.es/mailman/listinfo/kosmo_int
        -- 

        Sergio Baños Calvo

        Jefe de desarrollos
        Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
        Tlfno. móvil: 685005960
        Tlfno. fijo: (+34) 954788876

        E-mail: [hidden email]


    _______________________________________________
    Kosmo_int mailing list
    [hidden email]
    http://lists.saig.es/mailman/listinfo/kosmo_int
    -- 

    Sergio Baños Calvo

    Jefe de desarrollos
    Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
    Tlfno. móvil: 685005960
    Tlfno. fijo: (+34) 954788876

    E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0

Sergio Baños Calvo
Good afternoon, Jukka.

We finally decided to set the response reader charset to the one set at the request (utf-8): as you mentioned, the WFS response header is not reliable enough.

I have managed to build a developer update for Kosmo Desktop 2.0, you have it available at:

http://www.kosmoland.es/public/kosmo/v_2.0/binaries/kd_2.0_update_2011_05_19.zip

In order to install it, unzip the file and overwrite all the files at your Kosmo Desktop install directory. Remember that the changes are yet at developing stage and may contain bugs (I hope not ;)).

I have included a few more changes to the connector to improve usability:

1) When requesting the feature type schemas, a progress dialog is shown to let the user know the task progress.
2) In the attribute selection panel, if the feature type hasn't been correctly loaded or it doesn't contain a geometric attribute, it's disabled and won't be loaded afterwards.
3) In the attribute selection panel, it's possible to deselect a feature type and it won't be taken into account in the next panels (and it won't be loaded as a layer either)

Regards,

Hi,
 
I checked Geoserver version 2.1 rc2 on my own computer and deegree demo server at http://demo.deegree.org/deegree-wfs/services.  Both those are sending at least GetCapabilites response without having "charset=" in the headers.  Perhaps it is not very reliable to search the character encoding from WFS response headers.
 
-Jukka Rahkonen-


El 18/05/2011 15:42, Sergio Baños Calvo escribió:
Hi,

No problem about the previous reply ;).

I think i didn't explain myself correctly: TinyOWS is sending the response body correctly formated in UTF-8, but the response headers, that I used to set the charset for the request body reader, aren't filled correctly and the http client API can't get the charset from it, using ISO-8859-1 as returned value (the default one).

Comparing the two headers retrieved, seems that the IDEE WFS is adding "charset=UTF-8" to the request.

TinyOWS response headers:

Date: Wed, 18 May 2011 13:18:31 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/xml; subtype=gml/3.1.1


IDEE WFS response headers:

Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 18 May 2011 13:22:54 GMT


Anyway, it solved with the change I commented ;).

Regards,

El 18/05/2011 15:07, Rahkonen Jukka escribió:
Hi,
 
Sorry for the reply a minute ago without any comments.
First, I would really like to test the new client when it is possible.
 
Second, I will need to check the response headers.  However, I can see the encoding in the response body if I send this request with my browser
 
The result I am getting back begins with
 
<?xml version='1.0' encoding='UTF-8'?>
<wfs:FeatureCollection
 xmlns:tows='http://www.tinyows.org/'
 xmlns:lv='http://latuviitta.fi/'
 xmlns:wfs='http://www.opengis.net/wfs'
 
Perhaps that encoding information could be utilised?
 
I believe that with TinyOWS it will be wrong to believe that the result set is using the same encoding than the request. TinyOWS tells about a configuration parameter
encoding : OptionalOutput encoding. Default is UTF-8. Others values could be ISO-8859-1 for instance.
 
Thus I believe that if I set encoding to ISO-8859-1 it will be so even if I make request with UTF-8
 
-Jukka Rahkonen-
 
 


Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 18. toukokuuta 2011 15:49
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Hi,

Good news about the open issue: the connector have been improved again and it works now as expected:

[Image removed]

The problem with your TinyOWS is that, although I request it to send me the response in UTF-8, the response header doesn't contain any info about the response charset used (I have tested other servers, like the IDEE WFS server - http://www.idee.es/IDEE-WFS/ogcwebservice? -, and it fills the header correctly) and the http client takes ISO-8859-1 by default. So I have had to force the response reader to use the charset as if the server would always response as requested, and I have manage it to work that way.

I hope to have an update for testing tomorrow, if you like to test yourself.

Regards,

El 18/05/2011 9:32, Sergio Baños Calvo escribió:
Good morning Jukka.

The current WFS connector was using the first feature schema to build the layer schema, so that's the reason for the behaviour you commented in your mail. I have made some modifications to it in order to use the FeatureType schema instead, filtering out those attributes that have been unselected by the user, and it works right now :).

Respect to the filter issue, it's also related with the problem when reading the response from the server: it's not reading properly the response (sending the request). I will keep working on it today.

Regards,

El 17/05/2011 15:25, Sergio Baños Calvo escribió:
Hi, Jukka.

The osm_point layer works like a charm when removing the "tags" field, as you pointed in your previous mail.

Respect of the WFS reader, Kosmo Desktop WFS connector is based in OpenJUMP Degree WFS plugin. I'll check this afternoon the behaviour you're talking about with the lastest connector to see if the behaviour is the same after all the changes I'm doing to it.

The filter seems to be sent incorrectly, I'll check this also.

Regards,

El 17/05/2011 15:18, Rahkonen Jukka escribió:
Hi,
 
Some remarks on the WFS:
- Kosmo is using about the same WFS reader than gvSIG, or?  If yes, Kosmo may have same troubles than gvSIG (tested with version 1.11.0).
 
- Check the attribute table in Kosmo after doing GetFeature
 
Compare it with the layer schema
 
The resultset contains empty values for attribute "text3" and obviously therefore gvSIG builds an attribute table without that attribute.  The correct way would be to read the schema, make an empty table as an template and populate it then from the captured GML.
 
Also, I was not able to filter the "municipalities" feature type with a filter "kunta_ni1"='Saarijärvi'.  "kuknta_ni1"='Helsinki' does work, thus the error must be related to a non-ASCII character "ä".
 
-Jukka Rahkonen-
 
 


Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 13. toukokuuta 2011 13:30
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Hi Jukka.

Seems that the server is sending the response correctly, so it's a problem in client side: I'll revise how the request response is read, seems that it's ignoring the charset and it's reading it incorrectly.

Regards,

El 13/05/2011 12:07, Rahkonen Jukka escribió:
Hi,

Great progress!  You are right, some characters do not look right. You can try to compare with this direct GetFeature

http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=municipalities&maxfeatures=1

Data comes from PostGIS and it is UTF8 there. Most common non-ASCII charaters are a-uml, o-uml and a-ring
"äöåÄÖÅ", if they now look OK even through this mail.

-Jukka-


-----Alkuperäinen viesti-----
Lähettäjä: [hidden email] puolesta: Sergio Baños Calvo
Lähetetty: pe 13.5.2011 13:02
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0
 
Hi Jukka.

I did some adjustments to the connector yesterday and I could manage to 
load the layers municipalities, osm_line and osm_polygon (the osm_point 
layer keeps giving me problems with some characters in the attributes 
when I request 1.000 or more features).

Here it's a capture of the layer "municipalities" loaded in Kosmo 
Desktop. Could you confirm me that the attribute data hasn't been 
correctly retrieved (seems that some of the characters hasn't been read 
correctly in the fields "suural_ni1", "suural_ni2", "avi_n1" and "avi_n2")?

tinyows_municipalities


Regards,

El 12/05/2011 15:33, Rahkonen Jukka escribió:
Hi,
There may well be data errors in my current feature types because the 
OpenStreetMap data do not always convert easily into simple features 
and GML.  I have corrected some most obvious issues like renaming 
attributes like addr:housenumber into addr_housenumber but I am not 
surprised if there are some errors left. I should really add some more 
conventional feature types into the service and include other types of 
attributes than just strings.
I look forward to get my hands on your development version.
-Jukka Rahkonen-

    ------------------------------------------------------------------------
    *Lähettäjä:* [hidden email]
    [[hidden email]] *Puolesta *Sergio Baños Calvo
    *Lähetetty:* 12. toukokuuta 2011 16:23
    *Vastaanottaja:* International Kosmo mailing list (english languaje)
    *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

    Hi again Jukka.

    No problem for Kosmo Desktop, it's processing the operations in
    both ways, so the POST url (the one that uses Kosmo Desktop for
    connecting to the server) is being taken correctly (in the current
    development version, that error is present at the 2.0 official
    version).

    I have made some more testings in your server instance and seems
    that the connector is not retrieving properly some of the features
    from the server (it's giving errors when parsing the response when
    requesting 1.000 features). I'll keep you informed about any advances.

    Regards,

    El 12/05/2011 15:08, Rahkonen Jukka escribió:
    Hi,
    I may have found something new today, it is about how TinyOWS is
    listing the URLs for GetFeature in http GET vs. POST.  I have
    asked about is from deegree and TinyOWS user lists.  I believe
    you should check it as well. TinyOWS is announcing the GET and
    POST URLs in two separate ows:DCP elements while deegree and
    Geoserver are listing them as a list in one DCP element. I
    suspect that because of this OpenJUMP WFS plugin and iGeoDesktop
    do not find the Post URL at all.
    This is from deegree WFS
    <ows:OperationsMetadata xmlns="http://www.opengis.net/ows">
    <ows:Operation xmlns="http://www.opengis.net/ows" name="GetFeature">
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Get xmlns="http://www.opengis.net/ows"
    xlink:href="http://demo.deegree.org:80/deegree-wfs/services?"
    xlink:type="simple"></ows:Get>
    <ows:Post xmlns="http://www.opengis.net/ows"
    xlink:href="http://demo.deegree.org:80/deegree-wfs/services"
    xlink:type="simple"></ows:Post>
    </ows:HTTP>
    </ows:DCP>
    </ows:Operation>

    This is from TinyOWS
    <ows:Operation xmlns="http://www.opengis.net/ows" name="GetFeature">
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Get xmlns="http://www.opengis.net/ows"
    xlink:href="http://188.64.1.61/cgi-bin/tinyows?"></ows:Get
    <http://188.64.1.61/cgi-bin/tinyows?%22%3E%3C/ows:Get>>
    </ows:HTTP>
    </ows:DCP>
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Post xmlns="http://www.opengis.net/ows"
    xlink:href="http://188.64.1.61/cgi-bin/tinyows"></ows:Post
    <http://188.64.1.61/cgi-bin/tinyows%22%3E%3C/ows:Post>>
    </ows:HTTP>
    </ows:DCP>
    -Jukka Rahkonen-


        ------------------------------------------------------------------------
        *Lähettäjä:* [hidden email]
        [[hidden email]] *Puolesta *Sergio Baños Calvo
        *Lähetetty:* 12. toukokuuta 2011 16:00
        *Vastaanottaja:* International Kosmo mailing list (english
        languaje)
        *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

        Hi Jukka.

        Thank you very much for your assistance.

        I did some modifications to the WFS connector the first time
        but I didn't manage to connect to your old TinyOWS instance.

        I have made some testing over your new TinyOWS server and,
        after some adjustments to the WFS connector, I have finally
        got some data from it. The clue about the problem was given
        for a post made by you at the TinyOWS list (in this case the
        TinyOWS server response wasn't an internal server error like
        the last time, but a wrong content-type header exception):

        http://lists.maptools.org/pipermail/tinyows-users/2010-September/000193.html

        I'll try to generate a development version for testing in the
        next few days.

        Regards,

        El 12/05/2011 12:51, Rahkonen Jukka escribió:
        Hi,
        I sent some observations about Kosmo as a WFS client fot the
        TinyOWS server two months ago. Now I have updated my TinyOWS
        server into version 1.0 rc1 which is supposed to pass all
        the CITE WFS tests for both WFS 1.0.0 and 1.1.0. 
        Unfortunately after this update Kosmo does not get any
        further than reading the GetCapabilities and
        DescribeFeatureType.
        If you happen to have some development versions about the
        WFS client available I would be happy to do some testing. My
        WFS server is also open for you and it is still found at
        http://188.64.1.61/cgi-bin/tinyows?
        Regards,
        -Jukka Rahkonen-
        ------------------------------------------------------------------------
        *Lähettäjä:* [hidden email]
        [[hidden email]] *Puolesta *Sergio Baños Calvo
        *Lähetetty:* 10. maaliskuuta 2011 13:14
        *Vastaanottaja:* International Kosmo mailing list (english
        languaje)
        *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

            Hi again Jukka.

            Yes, the GetCapabilities and DescribeFeatureType
            requests works ok, but the problema arises when the
            GetFeature request is sent: as you mention in your next
            mail, Kosmo Desktop uses POST to get the features, so
            may be this is the problem.

            There isn't any clue in the "500 - Internal server
            error" response to get what's happening, it should be in
            the server log but the client doesn't get any hint.

            I started to translate Kosmo into Finnish and I hope I
            will have somehow usable language file next week. Where
            can I send it when it is ready?
            Great :). You can send it to me directly to my personal
            mail and we add a new update to the download web page.
            I'll need also the label you like to add to the
            contributors page.

            Regards,

            El 10/03/2011 10:05, Rahkonen Jukka escribió:
            Hi, and thanks for the answers.
            Sergio Baños Calvo  wrote:

            > I have tested your service (btw, thanks for it :) )
            > and, after correcting some code in the WFS connector
            > about XML parameters reading, I get to an
            > "500 - Internal server error". Could you check if
            > the server is working ok?
            GetFeature works for me both with WFS 1.0.0 and 1.1.0
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100>
            and
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100>
            GetCapabilities look good, as well as DescribeFeatureType
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point>
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point>
            I started to translate Kosmo into Finnish and I hope I
            will have somehow usable language file next week. Where
            can I send it when it is ready?
            -Jukka Rahkonen-


            _______________________________________________
            Kosmo_int mailing list
            [hidden email]
            http://lists.saig.es/mailman/listinfo/kosmo_int
            -- 

            Sergio Baños Calvo

            Jefe de desarrollos
            Sistemas Abiertos de Información Geográfica, S.L. (SAIG
            S.L.)
            Tlfno. móvil: 685005960
            Tlfno. fijo: (+34) 954788876

            E-mail: [hidden email]


        _______________________________________________
        Kosmo_int mailing list
        [hidden email]
        http://lists.saig.es/mailman/listinfo/kosmo_int
        -- 

        Sergio Baños Calvo

        Jefe de desarrollos
        Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
        Tlfno. móvil: 685005960
        Tlfno. fijo: (+34) 954788876

        E-mail: [hidden email]


    _______________________________________________
    Kosmo_int mailing list
    [hidden email]
    http://lists.saig.es/mailman/listinfo/kosmo_int
    -- 

    Sergio Baños Calvo

    Jefe de desarrollos
    Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
    Tlfno. móvil: 685005960
    Tlfno. fijo: (+34) 954788876

    E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0

Rahkonen Jukka
Hi,
 
I installed the developer update but I didn't manage to read features yet.  WFS driver is connecting with our WFS and a few others I tried, but somehow it looks like it does not send at all the final http POST GetFeature.  I was trying also the preconfigured services like IDEE-WFS.  GetCapabilities and DescribeFeatureType are successful but after GetFeature I am getting this error I get is: Error when making connection with server:http://www.idee.es/IDEE-WFS/ogcwebservice. Connection time out: connect.  Web traffic crawler does not capture anything so it looks like Kosmo does not manage to send the GetFeature at all.
 
I will have a try at home with direct internet connection and check if this has something to do with proxy.
 
Regards,
 
-Jukka Rahkonen-
 
 
 
 

Lähettäjä: [hidden email] [mailto:[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 19. toukokuuta 2011 17:04
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Good afternoon, Jukka.

We finally decided to set the response reader charset to the one set at the request (utf-8): as you mentioned, the WFS response header is not reliable enough.

I have managed to build a developer update for Kosmo Desktop 2.0, you have it available at:

http://www.kosmoland.es/public/kosmo/v_2.0/binaries/kd_2.0_update_2011_05_19.zip

In order to install it, unzip the file and overwrite all the files at your Kosmo Desktop install directory. Remember that the changes are yet at developing stage and may contain bugs (I hope not ;)).

I have included a few more changes to the connector to improve usability:

1) When requesting the feature type schemas, a progress dialog is shown to let the user know the task progress.
2) In the attribute selection panel, if the feature type hasn't been correctly loaded or it doesn't contain a geometric attribute, it's disabled and won't be loaded afterwards.
3) In the attribute selection panel, it's possible to deselect a feature type and it won't be taken into account in the next panels (and it won't be loaded as a layer either)

Regards,

Hi,
 
I checked Geoserver version 2.1 rc2 on my own computer and deegree demo server at http://demo.deegree.org/deegree-wfs/services.  Both those are sending at least GetCapabilites response without having "charset=" in the headers.  Perhaps it is not very reliable to search the character encoding from WFS response headers.
 
-Jukka Rahkonen-


El 18/05/2011 15:42, Sergio Baños Calvo escribió:
Hi,

No problem about the previous reply ;).

I think i didn't explain myself correctly: TinyOWS is sending the response body correctly formated in UTF-8, but the response headers, that I used to set the charset for the request body reader, aren't filled correctly and the http client API can't get the charset from it, using ISO-8859-1 as returned value (the default one).

Comparing the two headers retrieved, seems that the IDEE WFS is adding "charset=UTF-8" to the request.

TinyOWS response headers:

Date: Wed, 18 May 2011 13:18:31 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/xml; subtype=gml/3.1.1


IDEE WFS response headers:

Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 18 May 2011 13:22:54 GMT


Anyway, it solved with the change I commented ;).

Regards,

El 18/05/2011 15:07, Rahkonen Jukka escribió:
Hi,
 
Sorry for the reply a minute ago without any comments.
First, I would really like to test the new client when it is possible.
 
Second, I will need to check the response headers.  However, I can see the encoding in the response body if I send this request with my browser
 
The result I am getting back begins with
 
<?xml version='1.0' encoding='UTF-8'?>
<wfs:FeatureCollection
 xmlns:tows='http://www.tinyows.org/'
 xmlns:lv='http://latuviitta.fi/'
 xmlns:wfs='http://www.opengis.net/wfs'
 
Perhaps that encoding information could be utilised?
 
I believe that with TinyOWS it will be wrong to believe that the result set is using the same encoding than the request. TinyOWS tells about a configuration parameter
encoding : OptionalOutput encoding. Default is UTF-8. Others values could be ISO-8859-1 for instance.
 
Thus I believe that if I set encoding to ISO-8859-1 it will be so even if I make request with UTF-8
 
-Jukka Rahkonen-
 
 


Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 18. toukokuuta 2011 15:49
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Hi,

Good news about the open issue: the connector have been improved again and it works now as expected:

[Image removed]

The problem with your TinyOWS is that, although I request it to send me the response in UTF-8, the response header doesn't contain any info about the response charset used (I have tested other servers, like the IDEE WFS server - http://www.idee.es/IDEE-WFS/ogcwebservice? -, and it fills the header correctly) and the http client takes ISO-8859-1 by default. So I have had to force the response reader to use the charset as if the server would always response as requested, and I have manage it to work that way.

I hope to have an update for testing tomorrow, if you like to test yourself.

Regards,

El 18/05/2011 9:32, Sergio Baños Calvo escribió:
Good morning Jukka.

The current WFS connector was using the first feature schema to build the layer schema, so that's the reason for the behaviour you commented in your mail. I have made some modifications to it in order to use the FeatureType schema instead, filtering out those attributes that have been unselected by the user, and it works right now :).

Respect to the filter issue, it's also related with the problem when reading the response from the server: it's not reading properly the response (sending the request). I will keep working on it today.

Regards,

El 17/05/2011 15:25, Sergio Baños Calvo escribió:
Hi, Jukka.

The osm_point layer works like a charm when removing the "tags" field, as you pointed in your previous mail.

Respect of the WFS reader, Kosmo Desktop WFS connector is based in OpenJUMP Degree WFS plugin. I'll check this afternoon the behaviour you're talking about with the lastest connector to see if the behaviour is the same after all the changes I'm doing to it.

The filter seems to be sent incorrectly, I'll check this also.

Regards,

El 17/05/2011 15:18, Rahkonen Jukka escribió:
Hi,
 
Some remarks on the WFS:
- Kosmo is using about the same WFS reader than gvSIG, or?  If yes, Kosmo may have same troubles than gvSIG (tested with version 1.11.0).
 
- Check the attribute table in Kosmo after doing GetFeature
 
Compare it with the layer schema
 
The resultset contains empty values for attribute "text3" and obviously therefore gvSIG builds an attribute table without that attribute.  The correct way would be to read the schema, make an empty table as an template and populate it then from the captured GML.
 
Also, I was not able to filter the "municipalities" feature type with a filter "kunta_ni1"='Saarijärvi'.  "kuknta_ni1"='Helsinki' does work, thus the error must be related to a non-ASCII character "ä".
 
-Jukka Rahkonen-
 
 


Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 13. toukokuuta 2011 13:30
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Hi Jukka.

Seems that the server is sending the response correctly, so it's a problem in client side: I'll revise how the request response is read, seems that it's ignoring the charset and it's reading it incorrectly.

Regards,

El 13/05/2011 12:07, Rahkonen Jukka escribió:
Hi,

Great progress!  You are right, some characters do not look right. You can try to compare with this direct GetFeature

http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=municipalities&maxfeatures=1

Data comes from PostGIS and it is UTF8 there. Most common non-ASCII charaters are a-uml, o-uml and a-ring
"äöåÄÖÅ", if they now look OK even through this mail.

-Jukka-


-----Alkuperäinen viesti-----
Lähettäjä: [hidden email] puolesta: Sergio Baños Calvo
Lähetetty: pe 13.5.2011 13:02
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0
 
Hi Jukka.

I did some adjustments to the connector yesterday and I could manage to 
load the layers municipalities, osm_line and osm_polygon (the osm_point 
layer keeps giving me problems with some characters in the attributes 
when I request 1.000 or more features).

Here it's a capture of the layer "municipalities" loaded in Kosmo 
Desktop. Could you confirm me that the attribute data hasn't been 
correctly retrieved (seems that some of the characters hasn't been read 
correctly in the fields "suural_ni1", "suural_ni2", "avi_n1" and "avi_n2")?

tinyows_municipalities


Regards,

El 12/05/2011 15:33, Rahkonen Jukka escribió:
Hi,
There may well be data errors in my current feature types because the 
OpenStreetMap data do not always convert easily into simple features 
and GML.  I have corrected some most obvious issues like renaming 
attributes like addr:housenumber into addr_housenumber but I am not 
surprised if there are some errors left. I should really add some more 
conventional feature types into the service and include other types of 
attributes than just strings.
I look forward to get my hands on your development version.
-Jukka Rahkonen-

    ------------------------------------------------------------------------
    *Lähettäjä:* [hidden email]
    [[hidden email]] *Puolesta *Sergio Baños Calvo
    *Lähetetty:* 12. toukokuuta 2011 16:23
    *Vastaanottaja:* International Kosmo mailing list (english languaje)
    *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

    Hi again Jukka.

    No problem for Kosmo Desktop, it's processing the operations in
    both ways, so the POST url (the one that uses Kosmo Desktop for
    connecting to the server) is being taken correctly (in the current
    development version, that error is present at the 2.0 official
    version).

    I have made some more testings in your server instance and seems
    that the connector is not retrieving properly some of the features
    from the server (it's giving errors when parsing the response when
    requesting 1.000 features). I'll keep you informed about any advances.

    Regards,

    El 12/05/2011 15:08, Rahkonen Jukka escribió:
    Hi,
    I may have found something new today, it is about how TinyOWS is
    listing the URLs for GetFeature in http GET vs. POST.  I have
    asked about is from deegree and TinyOWS user lists.  I believe
    you should check it as well. TinyOWS is announcing the GET and
    POST URLs in two separate ows:DCP elements while deegree and
    Geoserver are listing them as a list in one DCP element. I
    suspect that because of this OpenJUMP WFS plugin and iGeoDesktop
    do not find the Post URL at all.
    This is from deegree WFS
    <ows:OperationsMetadata xmlns="http://www.opengis.net/ows">
    <ows:Operation xmlns="http://www.opengis.net/ows" name="GetFeature">
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Get xmlns="http://www.opengis.net/ows"
    xlink:href="http://demo.deegree.org:80/deegree-wfs/services?"
    xlink:type="simple"></ows:Get>
    <ows:Post xmlns="http://www.opengis.net/ows"
    xlink:href="http://demo.deegree.org:80/deegree-wfs/services"
    xlink:type="simple"></ows:Post>
    </ows:HTTP>
    </ows:DCP>
    </ows:Operation>

    This is from TinyOWS
    <ows:Operation xmlns="http://www.opengis.net/ows" name="GetFeature">
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Get xmlns="http://www.opengis.net/ows"
    xlink:href="http://188.64.1.61/cgi-bin/tinyows?"></ows:Get
    <http://188.64.1.61/cgi-bin/tinyows?%22%3E%3C/ows:Get>>
    </ows:HTTP>
    </ows:DCP>
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Post xmlns="http://www.opengis.net/ows"
    xlink:href="http://188.64.1.61/cgi-bin/tinyows"></ows:Post
    <http://188.64.1.61/cgi-bin/tinyows%22%3E%3C/ows:Post>>
    </ows:HTTP>
    </ows:DCP>
    -Jukka Rahkonen-


        ------------------------------------------------------------------------
        *Lähettäjä:* [hidden email]
        [[hidden email]] *Puolesta *Sergio Baños Calvo
        *Lähetetty:* 12. toukokuuta 2011 16:00
        *Vastaanottaja:* International Kosmo mailing list (english
        languaje)
        *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

        Hi Jukka.

        Thank you very much for your assistance.

        I did some modifications to the WFS connector the first time
        but I didn't manage to connect to your old TinyOWS instance.

        I have made some testing over your new TinyOWS server and,
        after some adjustments to the WFS connector, I have finally
        got some data from it. The clue about the problem was given
        for a post made by you at the TinyOWS list (in this case the
        TinyOWS server response wasn't an internal server error like
        the last time, but a wrong content-type header exception):

        http://lists.maptools.org/pipermail/tinyows-users/2010-September/000193.html

        I'll try to generate a development version for testing in the
        next few days.

        Regards,

        El 12/05/2011 12:51, Rahkonen Jukka escribió:
        Hi,
        I sent some observations about Kosmo as a WFS client fot the
        TinyOWS server two months ago. Now I have updated my TinyOWS
        server into version 1.0 rc1 which is supposed to pass all
        the CITE WFS tests for both WFS 1.0.0 and 1.1.0. 
        Unfortunately after this update Kosmo does not get any
        further than reading the GetCapabilities and
        DescribeFeatureType.
        If you happen to have some development versions about the
        WFS client available I would be happy to do some testing. My
        WFS server is also open for you and it is still found at
        http://188.64.1.61/cgi-bin/tinyows?
        Regards,
        -Jukka Rahkonen-
        ------------------------------------------------------------------------
        *Lähettäjä:* [hidden email]
        [[hidden email]] *Puolesta *Sergio Baños Calvo
        *Lähetetty:* 10. maaliskuuta 2011 13:14
        *Vastaanottaja:* International Kosmo mailing list (english
        languaje)
        *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

            Hi again Jukka.

            Yes, the GetCapabilities and DescribeFeatureType
            requests works ok, but the problema arises when the
            GetFeature request is sent: as you mention in your next
            mail, Kosmo Desktop uses POST to get the features, so
            may be this is the problem.

            There isn't any clue in the "500 - Internal server
            error" response to get what's happening, it should be in
            the server log but the client doesn't get any hint.

            I started to translate Kosmo into Finnish and I hope I
            will have somehow usable language file next week. Where
            can I send it when it is ready?
            Great :). You can send it to me directly to my personal
            mail and we add a new update to the download web page.
            I'll need also the label you like to add to the
            contributors page.

            Regards,

            El 10/03/2011 10:05, Rahkonen Jukka escribió:
            Hi, and thanks for the answers.
            Sergio Baños Calvo  wrote:

            > I have tested your service (btw, thanks for it :) )
            > and, after correcting some code in the WFS connector
            > about XML parameters reading, I get to an
            > "500 - Internal server error". Could you check if
            > the server is working ok?
            GetFeature works for me both with WFS 1.0.0 and 1.1.0
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100>
            and
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100>
            GetCapabilities look good, as well as DescribeFeatureType
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point>
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point>
            I started to translate Kosmo into Finnish and I hope I
            will have somehow usable language file next week. Where
            can I send it when it is ready?
            -Jukka Rahkonen-


            _______________________________________________
            Kosmo_int mailing list
            [hidden email]
            http://lists.saig.es/mailman/listinfo/kosmo_int
            -- 

            Sergio Baños Calvo

            Jefe de desarrollos
            Sistemas Abiertos de Información Geográfica, S.L. (SAIG
            S.L.)
            Tlfno. móvil: 685005960
            Tlfno. fijo: (+34) 954788876

            E-mail: [hidden email]


        _______________________________________________
        Kosmo_int mailing list
        [hidden email]
        http://lists.saig.es/mailman/listinfo/kosmo_int
        -- 

        Sergio Baños Calvo

        Jefe de desarrollos
        Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
        Tlfno. móvil: 685005960
        Tlfno. fijo: (+34) 954788876

        E-mail: [hidden email]


    _______________________________________________
    Kosmo_int mailing list
    [hidden email]
    http://lists.saig.es/mailman/listinfo/kosmo_int
    -- 

    Sergio Baños Calvo

    Jefe de desarrollos
    Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
    Tlfno. móvil: 685005960
    Tlfno. fijo: (+34) 954788876

    E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0

Sergio Baños Calvo-2
Hi Jukka.

If you configured the proxy settings at configuration dialog, it should use them, but may be we've missed them in the last step.

I'll check it later.

Regards,

El 19/05/2011 16:35, Rahkonen Jukka escribió:
Hi,
 
I installed the developer update but I didn't manage to read features yet.  WFS driver is connecting with our WFS and a few others I tried, but somehow it looks like it does not send at all the final http POST GetFeature.  I was trying also the preconfigured services like IDEE-WFS.  GetCapabilities and DescribeFeatureType are successful but after GetFeature I am getting this error I get is: Error when making connection with server:http://www.idee.es/IDEE-WFS/ogcwebservice. Connection time out: connect.  Web traffic crawler does not capture anything so it looks like Kosmo does not manage to send the GetFeature at all.
 
I will have a try at home with direct internet connection and check if this has something to do with proxy.
 
Regards,
 
-Jukka Rahkonen-
 
 
 
 

Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 19. toukokuuta 2011 17:04
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Good afternoon, Jukka.

We finally decided to set the response reader charset to the one set at the request (utf-8): as you mentioned, the WFS response header is not reliable enough.

I have managed to build a developer update for Kosmo Desktop 2.0, you have it available at:

http://www.kosmoland.es/public/kosmo/v_2.0/binaries/kd_2.0_update_2011_05_19.zip

In order to install it, unzip the file and overwrite all the files at your Kosmo Desktop install directory. Remember that the changes are yet at developing stage and may contain bugs (I hope not ;)).

I have included a few more changes to the connector to improve usability:

1) When requesting the feature type schemas, a progress dialog is shown to let the user know the task progress.
2) In the attribute selection panel, if the feature type hasn't been correctly loaded or it doesn't contain a geometric attribute, it's disabled and won't be loaded afterwards.
3) In the attribute selection panel, it's possible to deselect a feature type and it won't be taken into account in the next panels (and it won't be loaded as a layer either)

Regards,

Hi,
 
I checked Geoserver version 2.1 rc2 on my own computer and deegree demo server at http://demo.deegree.org/deegree-wfs/services.  Both those are sending at least GetCapabilites response without having "charset=" in the headers.  Perhaps it is not very reliable to search the character encoding from WFS response headers.
 
-Jukka Rahkonen-


El 18/05/2011 15:42, Sergio Baños Calvo escribió:
Hi,

No problem about the previous reply ;).

I think i didn't explain myself correctly: TinyOWS is sending the response body correctly formated in UTF-8, but the response headers, that I used to set the charset for the request body reader, aren't filled correctly and the http client API can't get the charset from it, using ISO-8859-1 as returned value (the default one).

Comparing the two headers retrieved, seems that the IDEE WFS is adding "charset=UTF-8" to the request.

TinyOWS response headers:

Date: Wed, 18 May 2011 13:18:31 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/xml; subtype=gml/3.1.1


IDEE WFS response headers:

Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 18 May 2011 13:22:54 GMT


Anyway, it solved with the change I commented ;).

Regards,

El 18/05/2011 15:07, Rahkonen Jukka escribió:
Hi,
 
Sorry for the reply a minute ago without any comments.
First, I would really like to test the new client when it is possible.
 
Second, I will need to check the response headers.  However, I can see the encoding in the response body if I send this request with my browser
 
The result I am getting back begins with
 
<?xml version='1.0' encoding='UTF-8'?>
<wfs:FeatureCollection
 xmlns:tows='http://www.tinyows.org/'
 xmlns:lv='http://latuviitta.fi/'
 xmlns:wfs='http://www.opengis.net/wfs'
 
Perhaps that encoding information could be utilised?
 
I believe that with TinyOWS it will be wrong to believe that the result set is using the same encoding than the request. TinyOWS tells about a configuration parameter
encoding : OptionalOutput encoding. Default is UTF-8. Others values could be ISO-8859-1 for instance.
 
Thus I believe that if I set encoding to ISO-8859-1 it will be so even if I make request with UTF-8
 
-Jukka Rahkonen-
 
 


Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 18. toukokuuta 2011 15:49
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Hi,

Good news about the open issue: the connector have been improved again and it works now as expected:

[Image removed]

The problem with your TinyOWS is that, although I request it to send me the response in UTF-8, the response header doesn't contain any info about the response charset used (I have tested other servers, like the IDEE WFS server - http://www.idee.es/IDEE-WFS/ogcwebservice? -, and it fills the header correctly) and the http client takes ISO-8859-1 by default. So I have had to force the response reader to use the charset as if the server would always response as requested, and I have manage it to work that way.

I hope to have an update for testing tomorrow, if you like to test yourself.

Regards,

El 18/05/2011 9:32, Sergio Baños Calvo escribió:
Good morning Jukka.

The current WFS connector was using the first feature schema to build the layer schema, so that's the reason for the behaviour you commented in your mail. I have made some modifications to it in order to use the FeatureType schema instead, filtering out those attributes that have been unselected by the user, and it works right now :).

Respect to the filter issue, it's also related with the problem when reading the response from the server: it's not reading properly the response (sending the request). I will keep working on it today.

Regards,

El 17/05/2011 15:25, Sergio Baños Calvo escribió:
Hi, Jukka.

The osm_point layer works like a charm when removing the "tags" field, as you pointed in your previous mail.

Respect of the WFS reader, Kosmo Desktop WFS connector is based in OpenJUMP Degree WFS plugin. I'll check this afternoon the behaviour you're talking about with the lastest connector to see if the behaviour is the same after all the changes I'm doing to it.

The filter seems to be sent incorrectly, I'll check this also.

Regards,

El 17/05/2011 15:18, Rahkonen Jukka escribió:
Hi,
 
Some remarks on the WFS:
- Kosmo is using about the same WFS reader than gvSIG, or?  If yes, Kosmo may have same troubles than gvSIG (tested with version 1.11.0).
 
- Check the attribute table in Kosmo after doing GetFeature
 
Compare it with the layer schema
 
The resultset contains empty values for attribute "text3" and obviously therefore gvSIG builds an attribute table without that attribute.  The correct way would be to read the schema, make an empty table as an template and populate it then from the captured GML.
 
Also, I was not able to filter the "municipalities" feature type with a filter "kunta_ni1"='Saarijärvi'.  "kuknta_ni1"='Helsinki' does work, thus the error must be related to a non-ASCII character "ä".
 
-Jukka Rahkonen-
 
 


Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 13. toukokuuta 2011 13:30
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Hi Jukka.

Seems that the server is sending the response correctly, so it's a problem in client side: I'll revise how the request response is read, seems that it's ignoring the charset and it's reading it incorrectly.

Regards,

El 13/05/2011 12:07, Rahkonen Jukka escribió:
Hi,

Great progress!  You are right, some characters do not look right. You can try to compare with this direct GetFeature

http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=municipalities&maxfeatures=1

Data comes from PostGIS and it is UTF8 there. Most common non-ASCII charaters are a-uml, o-uml and a-ring
"äöåÄÖÅ", if they now look OK even through this mail.

-Jukka-


-----Alkuperäinen viesti-----
Lähettäjä: [hidden email] puolesta: Sergio Baños Calvo
Lähetetty: pe 13.5.2011 13:02
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0
 
Hi Jukka.

I did some adjustments to the connector yesterday and I could manage to 
load the layers municipalities, osm_line and osm_polygon (the osm_point 
layer keeps giving me problems with some characters in the attributes 
when I request 1.000 or more features).

Here it's a capture of the layer "municipalities" loaded in Kosmo 
Desktop. Could you confirm me that the attribute data hasn't been 
correctly retrieved (seems that some of the characters hasn't been read 
correctly in the fields "suural_ni1", "suural_ni2", "avi_n1" and "avi_n2")?

tinyows_municipalities


Regards,

El 12/05/2011 15:33, Rahkonen Jukka escribió:
Hi,
There may well be data errors in my current feature types because the 
OpenStreetMap data do not always convert easily into simple features 
and GML.  I have corrected some most obvious issues like renaming 
attributes like addr:housenumber into addr_housenumber but I am not 
surprised if there are some errors left. I should really add some more 
conventional feature types into the service and include other types of 
attributes than just strings.
I look forward to get my hands on your development version.
-Jukka Rahkonen-

    ------------------------------------------------------------------------
    *Lähettäjä:* [hidden email]
    [[hidden email]] *Puolesta *Sergio Baños Calvo
    *Lähetetty:* 12. toukokuuta 2011 16:23
    *Vastaanottaja:* International Kosmo mailing list (english languaje)
    *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

    Hi again Jukka.

    No problem for Kosmo Desktop, it's processing the operations in
    both ways, so the POST url (the one that uses Kosmo Desktop for
    connecting to the server) is being taken correctly (in the current
    development version, that error is present at the 2.0 official
    version).

    I have made some more testings in your server instance and seems
    that the connector is not retrieving properly some of the features
    from the server (it's giving errors when parsing the response when
    requesting 1.000 features). I'll keep you informed about any advances.

    Regards,

    El 12/05/2011 15:08, Rahkonen Jukka escribió:
    Hi,
    I may have found something new today, it is about how TinyOWS is
    listing the URLs for GetFeature in http GET vs. POST.  I have
    asked about is from deegree and TinyOWS user lists.  I believe
    you should check it as well. TinyOWS is announcing the GET and
    POST URLs in two separate ows:DCP elements while deegree and
    Geoserver are listing them as a list in one DCP element. I
    suspect that because of this OpenJUMP WFS plugin and iGeoDesktop
    do not find the Post URL at all.
    This is from deegree WFS
    <ows:OperationsMetadata xmlns="http://www.opengis.net/ows">
    <ows:Operation xmlns="http://www.opengis.net/ows" name="GetFeature">
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Get xmlns="http://www.opengis.net/ows"
    xlink:href="http://demo.deegree.org:80/deegree-wfs/services?"
    xlink:type="simple"></ows:Get>
    <ows:Post xmlns="http://www.opengis.net/ows"
    xlink:href="http://demo.deegree.org:80/deegree-wfs/services"
    xlink:type="simple"></ows:Post>
    </ows:HTTP>
    </ows:DCP>
    </ows:Operation>

    This is from TinyOWS
    <ows:Operation xmlns="http://www.opengis.net/ows" name="GetFeature">
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Get xmlns="http://www.opengis.net/ows"
    xlink:href="http://188.64.1.61/cgi-bin/tinyows?"></ows:Get
    <http://188.64.1.61/cgi-bin/tinyows?%22%3E%3C/ows:Get>>
    </ows:HTTP>
    </ows:DCP>
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Post xmlns="http://www.opengis.net/ows"
    xlink:href="http://188.64.1.61/cgi-bin/tinyows"></ows:Post
    <http://188.64.1.61/cgi-bin/tinyows%22%3E%3C/ows:Post>>
    </ows:HTTP>
    </ows:DCP>
    -Jukka Rahkonen-


        ------------------------------------------------------------------------
        *Lähettäjä:* [hidden email]
        [[hidden email]] *Puolesta *Sergio Baños Calvo
        *Lähetetty:* 12. toukokuuta 2011 16:00
        *Vastaanottaja:* International Kosmo mailing list (english
        languaje)
        *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

        Hi Jukka.

        Thank you very much for your assistance.

        I did some modifications to the WFS connector the first time
        but I didn't manage to connect to your old TinyOWS instance.

        I have made some testing over your new TinyOWS server and,
        after some adjustments to the WFS connector, I have finally
        got some data from it. The clue about the problem was given
        for a post made by you at the TinyOWS list (in this case the
        TinyOWS server response wasn't an internal server error like
        the last time, but a wrong content-type header exception):

        http://lists.maptools.org/pipermail/tinyows-users/2010-September/000193.html

        I'll try to generate a development version for testing in the
        next few days.

        Regards,

        El 12/05/2011 12:51, Rahkonen Jukka escribió:
        Hi,
        I sent some observations about Kosmo as a WFS client fot the
        TinyOWS server two months ago. Now I have updated my TinyOWS
        server into version 1.0 rc1 which is supposed to pass all
        the CITE WFS tests for both WFS 1.0.0 and 1.1.0. 
        Unfortunately after this update Kosmo does not get any
        further than reading the GetCapabilities and
        DescribeFeatureType.
        If you happen to have some development versions about the
        WFS client available I would be happy to do some testing. My
        WFS server is also open for you and it is still found at
        http://188.64.1.61/cgi-bin/tinyows?
        Regards,
        -Jukka Rahkonen-
        ------------------------------------------------------------------------
        *Lähettäjä:* [hidden email]
        [[hidden email]] *Puolesta *Sergio Baños Calvo
        *Lähetetty:* 10. maaliskuuta 2011 13:14
        *Vastaanottaja:* International Kosmo mailing list (english
        languaje)
        *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

            Hi again Jukka.

            Yes, the GetCapabilities and DescribeFeatureType
            requests works ok, but the problema arises when the
            GetFeature request is sent: as you mention in your next
            mail, Kosmo Desktop uses POST to get the features, so
            may be this is the problem.

            There isn't any clue in the "500 - Internal server
            error" response to get what's happening, it should be in
            the server log but the client doesn't get any hint.

            I started to translate Kosmo into Finnish and I hope I
            will have somehow usable language file next week. Where
            can I send it when it is ready?
            Great :). You can send it to me directly to my personal
            mail and we add a new update to the download web page.
            I'll need also the label you like to add to the
            contributors page.

            Regards,

            El 10/03/2011 10:05, Rahkonen Jukka escribió:
            Hi, and thanks for the answers.
            Sergio Baños Calvo  wrote:

            > I have tested your service (btw, thanks for it :) )
            > and, after correcting some code in the WFS connector
            > about XML parameters reading, I get to an
            > "500 - Internal server error". Could you check if
            > the server is working ok?
            GetFeature works for me both with WFS 1.0.0 and 1.1.0
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100>
            and
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100>
            GetCapabilities look good, as well as DescribeFeatureType
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point>
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point>
            I started to translate Kosmo into Finnish and I hope I
            will have somehow usable language file next week. Where
            can I send it when it is ready?
            -Jukka Rahkonen-


            _______________________________________________
            Kosmo_int mailing list
            [hidden email]
            http://lists.saig.es/mailman/listinfo/kosmo_int
            -- 

            Sergio Baños Calvo

            Jefe de desarrollos
            Sistemas Abiertos de Información Geográfica, S.L. (SAIG
            S.L.)
            Tlfno. móvil: 685005960
            Tlfno. fijo: (+34) 954788876

            E-mail: [hidden email]


        _______________________________________________
        Kosmo_int mailing list
        [hidden email]
        http://lists.saig.es/mailman/listinfo/kosmo_int
        -- 

        Sergio Baños Calvo

        Jefe de desarrollos
        Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
        Tlfno. móvil: 685005960
        Tlfno. fijo: (+34) 954788876

        E-mail: [hidden email]


    _______________________________________________
    Kosmo_int mailing list
    [hidden email]
    http://lists.saig.es/mailman/listinfo/kosmo_int
    -- 

    Sergio Baños Calvo

    Jefe de desarrollos
    Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
    Tlfno. móvil: 685005960
    Tlfno. fijo: (+34) 954788876

    E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0

Rahkonen Jukka
Hi,

The develompent WFS works extraordinary well with TinyOWS and WFS 1.1.0. I believe that proxy had nothing to do with my problems but it was because I used the default WFS version 1.0.0. and with that version the final GetFeatures are failing.  

I haven't tried spatial filters yet but plain GetFeatures and attribute filters seem to work very well against my TinyOWS. Even the non-ASCII characters can be used in filter, and filters with OR work as well. Pretty well done, thanks!

Are you planning to make some minory release of Kosmo that would include these WFS enhancements sometimes soon?

-Jukka Rahkonen-


-----Alkuperäinen viesti-----
Lähettäjä: [hidden email] puolesta: Sergio Baños Calvo
Lähetetty: to 19.5.2011 18:51
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0
 
Hi Jukka.

If you configured the proxy settings at configuration dialog, it should
use them, but may be we've missed them in the last step.

I'll check it later.

Regards,

El 19/05/2011 16:35, Rahkonen Jukka escribió:

> Hi,
> I installed the developer update but I didn't manage to read features
> yet.  WFS driver is connecting with our WFS and a few others I tried,
> but somehow it looks like it does not send at all the final http POST
> GetFeature.  I was trying also the preconfigured services like
> IDEE-WFS.  GetCapabilities and DescribeFeatureType are successful but
> after GetFeature I am getting this error I get is: Error when making
> connection with
> server:http://www.idee.es/IDEE-WFS/ogcwebservice. Connection time out:
> connect.  Web traffic crawler does not capture anything so it looks
> like Kosmo does not manage to send the GetFeature at all.
> I will have a try at home with direct internet connection and check if
> this has something to do with proxy.
> Regards,
> -Jukka Rahkonen-
> ------------------------------------------------------------------------
> *Lähettäjä:* [hidden email]
> [mailto:[hidden email]] *Puolesta *Sergio Baños Calvo
> *Lähetetty:* 19. toukokuuta 2011 17:04
> *Vastaanottaja:* International Kosmo mailing list (english languaje)
> *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0
>
>     Good afternoon, Jukka.
>
>     We finally decided to set the response reader charset to the one
>     set at the request (utf-8): as you mentioned, the WFS response
>     header is not reliable enough.
>
>     I have managed to build a developer update for Kosmo Desktop 2.0,
>     you have it available at:
>
>     http://www.kosmoland.es/public/kosmo/v_2.0/binaries/kd_2.0_update_2011_05_19.zip
>
>     In order to install it, unzip the file and overwrite all the files
>     at your Kosmo Desktop install directory. Remember that the changes
>     are yet at developing stage and may contain bugs (I hope not ;)).
>
>     I have included a few more changes to the connector to improve
>     usability:
>
>     1) When requesting the feature type schemas, a progress dialog is
>     shown to let the user know the task progress.
>     2) In the attribute selection panel, if the feature type hasn't
>     been correctly loaded or it doesn't contain a geometric attribute,
>     it's disabled and won't be loaded afterwards.
>     3) In the attribute selection panel, it's possible to deselect a
>     feature type and it won't be taken into account in the next panels
>     (and it won't be loaded as a layer either)
>
>     Regards,
>
>>     Hi,
>>     I checked Geoserver version 2.1 rc2 on my own computer and
>>     deegree demo server at
>>     http://demo.deegree.org/deegree-wfs/services.  Both those are
>>     sending at least GetCapabilites response without having
>>     "charset=" in the headers.  Perhaps it is not very reliable to
>>     search the character encoding from WFS response headers.
>>     -Jukka Rahkonen-
>
>
>     El 18/05/2011 15:42, Sergio Baños Calvo escribió:
>>     Hi,
>>
>>     No problem about the previous reply ;).
>>
>>     I think i didn't explain myself correctly: TinyOWS is sending the
>>     response body correctly formated in UTF-8, but the response
>>     headers, that I used to set the charset for the request body
>>     reader, aren't filled correctly and the http client API can't get
>>     the charset from it, using ISO-8859-1 as returned value (the
>>     default one).
>>
>>     Comparing the two headers retrieved, seems that the IDEE WFS is
>>     adding "charset=UTF-8" to the request.
>>
>>     TinyOWS response headers:
>>
>>     Date: Wed, 18 May 2011 13:18:31 GMT
>>     Server: Apache/2.2.14 (Ubuntu)
>>     Vary: Accept-Encoding
>>     Transfer-Encoding: chunked
>>     Content-Type: text/xml; subtype=gml/3.1.1
>>
>>
>>     IDEE WFS response headers:
>>
>>     Server: Apache-Coyote/1.1
>>     Content-Type: text/xml;charset=UTF-8
>>     Transfer-Encoding: chunked
>>     Date: Wed, 18 May 2011 13:22:54 GMT
>>
>>
>>     Anyway, it solved with the change I commented ;).
>>
>>     Regards,
>>
>>     El 18/05/2011 15:07, Rahkonen Jukka escribió:
>>>     Hi,
>>>     Sorry for the reply a minute ago without any comments.
>>>     First, I would really like to test the new client when it is
>>>     possible.
>>>     Second, I will need to check the response headers.  However, I
>>>     can see the encoding in the response body if I send this request
>>>     with my browser
>>>     http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=municipalities&maxfeatures=2
>>>     <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=municipalities&maxfeatures=2>
>>>     The result I am getting back begins with
>>>     <?xml version='1.0' encoding='UTF-8'?>
>>>     <wfs:FeatureCollection
>>>      xmlns:tows='http://www.tinyows.org/'
>>>      xmlns:lv='http://latuviitta.fi/'
>>>      xmlns:wfs='http://www.opengis.net/wfs'
>>>     Perhaps that encoding information could be utilised?
>>>     I believe that with TinyOWS it will be wrong to believe that the
>>>     result set is using the same encoding than the request. TinyOWS
>>>     tells about a configuration parameter
>>>     encoding : OptionalOutput encoding. Default is UTF-8. Others
>>>     values could be ISO-8859-1 for instance.
>>>     Thus I believe that if I set encoding to ISO-8859-1 it will be
>>>     so even if I make request with UTF-8
>>>     -Jukka Rahkonen-
>>>
>>>         ------------------------------------------------------------------------
>>>         *Lähettäjä:* [hidden email]
>>>         [mailto:[hidden email]] *Puolesta *Sergio Baños Calvo
>>>         *Lähetetty:* 18. toukokuuta 2011 15:49
>>>         *Vastaanottaja:* International Kosmo mailing list (english
>>>         languaje)
>>>         *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0
>>>
>>>         Hi,
>>>
>>>         Good news about the open issue: the connector have been
>>>         improved again and it works now as expected:
>>>
>>>         [Image removed]
>>>
>>>         The problem with your TinyOWS is that, although I request it
>>>         to send me the response in UTF-8, the response header
>>>         doesn't contain any info about the response charset used (I
>>>         have tested other servers, like the IDEE WFS server -
>>>         http://www.idee.es/IDEE-WFS/ogcwebservice? -, and it fills
>>>         the header correctly) and the http client takes ISO-8859-1
>>>         by default. So I have had to force the response reader to
>>>         use the charset as if the server would always response as
>>>         requested, and I have manage it to work that way.
>>>
>>>         I hope to have an update for testing tomorrow, if you like
>>>         to test yourself.
>>>
>>>         Regards,
>>>
>>>         El 18/05/2011 9:32, Sergio Baños Calvo escribió:
>>>>         Good morning Jukka.
>>>>
>>>>         The current WFS connector was using the first feature
>>>>         schema to build the layer schema, so that's the reason for
>>>>         the behaviour you commented in your mail. I have made some
>>>>         modifications to it in order to use the FeatureType schema
>>>>         instead, filtering out those attributes that have been
>>>>         unselected by the user, and it works right now :).
>>>>
>>>>         Respect to the filter issue, it's also related with the
>>>>         problem when reading the response from the server: it's not
>>>>         reading properly the response (sending the request). I will
>>>>         keep working on it today.
>>>>
>>>>         Regards,
>>>>
>>>>         El 17/05/2011 15:25, Sergio Baños Calvo escribió:
>>>>>         Hi, Jukka.
>>>>>
>>>>>         The osm_point layer works like a charm when removing the
>>>>>         "tags" field, as you pointed in your previous mail.
>>>>>
>>>>>         Respect of the WFS reader, Kosmo Desktop WFS connector is
>>>>>         based in OpenJUMP Degree WFS plugin. I'll check this
>>>>>         afternoon the behaviour you're talking about with the
>>>>>         lastest connector to see if the behaviour is the same
>>>>>         after all the changes I'm doing to it.
>>>>>
>>>>>         The filter seems to be sent incorrectly, I'll check this also.
>>>>>
>>>>>         Regards,
>>>>>
>>>>>         El 17/05/2011 15:18, Rahkonen Jukka escribió:
>>>>>>         Hi,
>>>>>>         Some remarks on the WFS:
>>>>>>         - Kosmo is using about the same WFS reader than gvSIG,
>>>>>>         or?  If yes, Kosmo may have same troubles than gvSIG
>>>>>>         (tested with version 1.11.0).
>>>>>>         - Check the attribute table in Kosmo after doing GetFeature
>>>>>>         http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=lv:mml_cityp&maxfeatures=10
>>>>>>         <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=lv:mml_cityp&maxfeatures=10>
>>>>>>         Compare it with the layer schema
>>>>>>         http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=lv:mml_cityp
>>>>>>         <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=lv:mml_cityp>
>>>>>>         The resultset contains empty values for attribute "text3"
>>>>>>         and obviously therefore gvSIG builds an attribute table
>>>>>>         without that attribute.  The correct way would be to read
>>>>>>         the schema, make an empty table as an template and
>>>>>>         populate it then from the captured GML.
>>>>>>         Also, I was not able to filter the "municipalities"
>>>>>>         feature type with a filter "kunta_ni1"='Saarijärvi'.
>>>>>>         "kuknta_ni1"='Helsinki' does work, thus the error must be
>>>>>>         related to a non-ASCII character "ä".
>>>>>>         -Jukka Rahkonen-
>>>>>>
>>>>>>             ------------------------------------------------------------------------
>>>>>>             *Lähettäjä:* [hidden email]
>>>>>>             [mailto:[hidden email]] *Puolesta *Sergio
>>>>>>             Baños Calvo
>>>>>>             *Lähetetty:* 13. toukokuuta 2011 13:30
>>>>>>             *Vastaanottaja:* International Kosmo mailing list
>>>>>>             (english languaje)
>>>>>>             *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0
>>>>>>
>>>>>>             Hi Jukka.
>>>>>>
>>>>>>             Seems that the server is sending the response
>>>>>>             correctly, so it's a problem in client side: I'll
>>>>>>             revise how the request response is read, seems that
>>>>>>             it's ignoring the charset and it's reading it
>>>>>>             incorrectly.
>>>>>>
>>>>>>             Regards,
>>>>>>
>>>>>>             El 13/05/2011 12:07, Rahkonen Jukka escribió:
>>>>>>>             Hi,
>>>>>>>
>>>>>>>             Great progress!  You are right, some characters do not look right. You can try to compare with this direct GetFeature
>>>>>>>
>>>>>>>             http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=municipalities&maxfeatures=1
>>>>>>>
>>>>>>>             Data comes from PostGIS and it is UTF8 there. Most common non-ASCII charaters are a-uml, o-uml and a-ring
>>>>>>>             "äöåÄÖÅ", if they now look OK even through this mail.
>>>>>>>
>>>>>>>             -Jukka-
>>>>>>>
>>>>>>>
>>>>>>>             -----Alkuperäinen viesti-----
>>>>>>>             Lähettäjä:[hidden email]  puolesta: Sergio Baños Calvo
>>>>>>>             Lähetetty: pe 13.5.2011 13:02
>>>>>>>             Vastaanottaja: International Kosmo mailing list (english languaje)
>>>>>>>             Aihe: Re: [Kosmo_int] Testing Kosmo 2.0
>>>>>>>
>>>>>>>             Hi Jukka.
>>>>>>>
>>>>>>>             I did some adjustments to the connector yesterday and I could manage to
>>>>>>>             load the layers municipalities, osm_line and osm_polygon (the osm_point
>>>>>>>             layer keeps giving me problems with some characters in the attributes
>>>>>>>             when I request 1.000 or more features).
>>>>>>>
>>>>>>>             Here it's a capture of the layer "municipalities" loaded in Kosmo
>>>>>>>             Desktop. Could you confirm me that the attribute data hasn't been
>>>>>>>             correctly retrieved (seems that some of the characters hasn't been read
>>>>>>>             correctly in the fields "suural_ni1", "suural_ni2", "avi_n1" and "avi_n2")?
>>>>>>>
>>>>>>>             tinyows_municipalities
>>>>>>>
>>>>>>>
>>>>>>>             Regards,
>>>>>>>
>>>>>>>             El 12/05/2011 15:33, Rahkonen Jukka escribió:
>>>>>>>>             Hi,
>>>>>>>>             There may well be data errors in my current feature types because the
>>>>>>>>             OpenStreetMap data do not always convert easily into simple features
>>>>>>>>             and GML.  I have corrected some most obvious issues like renaming
>>>>>>>>             attributes like addr:housenumber into addr_housenumber but I am not
>>>>>>>>             surprised if there are some errors left. I should really add some more
>>>>>>>>             conventional feature types into the service and include other types of
>>>>>>>>             attributes than just strings.
>>>>>>>>             I look forward to get my hands on your development version.
>>>>>>>>             -Jukka Rahkonen-
>>>>>>>>
>>>>>>>>                  ------------------------------------------------------------------------
>>>>>>>>                  *Lähettäjä:*[hidden email]
>>>>>>>>                  [mailto:[hidden email]] *Puolesta *Sergio Baños Calvo
>>>>>>>>                  *Lähetetty:* 12. toukokuuta 2011 16:23
>>>>>>>>                  *Vastaanottaja:* International Kosmo mailing list (english languaje)
>>>>>>>>                  *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0
>>>>>>>>
>>>>>>>>                  Hi again Jukka.
>>>>>>>>
>>>>>>>>                  No problem for Kosmo Desktop, it's processing the operations in
>>>>>>>>                  both ways, so the POST url (the one that uses Kosmo Desktop for
>>>>>>>>                  connecting to the server) is being taken correctly (in the current
>>>>>>>>                  development version, that error is present at the 2.0 official
>>>>>>>>                  version).
>>>>>>>>
>>>>>>>>                  I have made some more testings in your server instance and seems
>>>>>>>>                  that the connector is not retrieving properly some of the features
>>>>>>>>                  from the server (it's giving errors when parsing the response when
>>>>>>>>                  requesting 1.000 features). I'll keep you informed about any advances.
>>>>>>>>
>>>>>>>>                  Regards,
>>>>>>>>
>>>>>>>>                  El 12/05/2011 15:08, Rahkonen Jukka escribió:
>>>>>>>>>                  Hi,
>>>>>>>>>                  I may have found something new today, it is about how TinyOWS is
>>>>>>>>>                  listing the URLs for GetFeature in http GET vs. POST.  I have
>>>>>>>>>                  asked about is from deegree and TinyOWS user lists.  I believe
>>>>>>>>>                  you should check it as well. TinyOWS is announcing the GET and
>>>>>>>>>                  POST URLs in two separate ows:DCP elements while deegree and
>>>>>>>>>                  Geoserver are listing them as a list in one DCP element. I
>>>>>>>>>                  suspect that because of this OpenJUMP WFS plugin and iGeoDesktop
>>>>>>>>>                  do not find the Post URL at all.
>>>>>>>>>                  This is from deegree WFS
>>>>>>>>>                  <ows:OperationsMetadata xmlns="http://www.opengis.net/ows">
>>>>>>>>>                  <ows:Operation xmlns="http://www.opengis.net/ows"  name="GetFeature">
>>>>>>>>>                  <ows:DCP xmlns="http://www.opengis.net/ows">
>>>>>>>>>                  <ows:HTTP xmlns="http://www.opengis.net/ows">
>>>>>>>>>                  <ows:Get xmlns="http://www.opengis.net/ows"
>>>>>>>>>                  xlink:href="http://demo.deegree.org:80/deegree-wfs/services?"
>>>>>>>>>                  xlink:type="simple"></ows:Get>
>>>>>>>>>                  <ows:Post xmlns="http://www.opengis.net/ows"
>>>>>>>>>                  xlink:href="http://demo.deegree.org:80/deegree-wfs/services"
>>>>>>>>>                  xlink:type="simple"></ows:Post>
>>>>>>>>>                  </ows:HTTP>
>>>>>>>>>                  </ows:DCP>
>>>>>>>>>                  </ows:Operation>
>>>>>>>>>
>>>>>>>>>                  This is from TinyOWS
>>>>>>>>>                  <ows:Operation xmlns="http://www.opengis.net/ows"  name="GetFeature">
>>>>>>>>>                  <ows:DCP xmlns="http://www.opengis.net/ows">
>>>>>>>>>                  <ows:HTTP xmlns="http://www.opengis.net/ows">
>>>>>>>>>                  <ows:Get xmlns="http://www.opengis.net/ows"
>>>>>>>>>                  xlink:href="http://188.64.1.61/cgi-bin/tinyows?"></ows:Get
>>>>>>>>>                  <http://188.64.1.61/cgi-bin/tinyows?%22%3E%3C/ows:Get>>
>>>>>>>>>                  </ows:HTTP>
>>>>>>>>>                  </ows:DCP>
>>>>>>>>>                  <ows:DCP xmlns="http://www.opengis.net/ows">
>>>>>>>>>                  <ows:HTTP xmlns="http://www.opengis.net/ows">
>>>>>>>>>                  <ows:Post xmlns="http://www.opengis.net/ows"
>>>>>>>>>                  xlink:href="http://188.64.1.61/cgi-bin/tinyows"></ows:Post
>>>>>>>>>                  <http://188.64.1.61/cgi-bin/tinyows%22%3E%3C/ows:Post>>
>>>>>>>>>                  </ows:HTTP>
>>>>>>>>>                  </ows:DCP>
>>>>>>>>>                  -Jukka Rahkonen-
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                      ------------------------------------------------------------------------
>>>>>>>>>                      *Lähettäjä:*[hidden email]
>>>>>>>>>                      [mailto:[hidden email]] *Puolesta *Sergio Baños Calvo
>>>>>>>>>                      *Lähetetty:* 12. toukokuuta 2011 16:00
>>>>>>>>>                      *Vastaanottaja:* International Kosmo mailing list (english
>>>>>>>>>                      languaje)
>>>>>>>>>                      *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0
>>>>>>>>>
>>>>>>>>>                      Hi Jukka.
>>>>>>>>>
>>>>>>>>>                      Thank you very much for your assistance.
>>>>>>>>>
>>>>>>>>>                      I did some modifications to the WFS connector the first time
>>>>>>>>>                      but I didn't manage to connect to your old TinyOWS instance.
>>>>>>>>>
>>>>>>>>>                      I have made some testing over your new TinyOWS server and,
>>>>>>>>>                      after some adjustments to the WFS connector, I have finally
>>>>>>>>>                      got some data from it. The clue about the problem was given
>>>>>>>>>                      for a post made by you at the TinyOWS list (in this case the
>>>>>>>>>                      TinyOWS server response wasn't an internal server error like
>>>>>>>>>                      the last time, but a wrong content-type header exception):
>>>>>>>>>
>>>>>>>>>                      http://lists.maptools.org/pipermail/tinyows-users/2010-September/000193.html
>>>>>>>>>
>>>>>>>>>                      I'll try to generate a development version for testing in the
>>>>>>>>>                      next few days.
>>>>>>>>>
>>>>>>>>>                      Regards,
>>>>>>>>>
>>>>>>>>>                      El 12/05/2011 12:51, Rahkonen Jukka escribió:
>>>>>>>>>>                      Hi,
>>>>>>>>>>                      I sent some observations about Kosmo as a WFS client fot the
>>>>>>>>>>                      TinyOWS server two months ago. Now I have updated my TinyOWS
>>>>>>>>>>                      server into version 1.0 rc1 which is supposed to pass all
>>>>>>>>>>                      the CITE WFS tests for both WFS 1.0.0 and 1.1.0.
>>>>>>>>>>                      Unfortunately after this update Kosmo does not get any
>>>>>>>>>>                      further than reading the GetCapabilities and
>>>>>>>>>>                      DescribeFeatureType.
>>>>>>>>>>                      If you happen to have some development versions about the
>>>>>>>>>>                      WFS client available I would be happy to do some testing. My
>>>>>>>>>>                      WFS server is also open for you and it is still found at
>>>>>>>>>>                      http://188.64.1.61/cgi-bin/tinyows?
>>>>>>>>>>                      Regards,
>>>>>>>>>>                      -Jukka Rahkonen-
>>>>>>>>>>                      ------------------------------------------------------------------------
>>>>>>>>>>                      *Lähettäjä:*[hidden email]
>>>>>>>>>>                      [mailto:[hidden email]] *Puolesta *Sergio Baños Calvo
>>>>>>>>>>                      *Lähetetty:* 10. maaliskuuta 2011 13:14
>>>>>>>>>>                      *Vastaanottaja:* International Kosmo mailing list (english
>>>>>>>>>>                      languaje)
>>>>>>>>>>                      *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0
>>>>>>>>>>
>>>>>>>>>>                          Hi again Jukka.
>>>>>>>>>>
>>>>>>>>>>                          Yes, the GetCapabilities and DescribeFeatureType
>>>>>>>>>>                          requests works ok, but the problema arises when the
>>>>>>>>>>                          GetFeature request is sent: as you mention in your next
>>>>>>>>>>                          mail, Kosmo Desktop uses POST to get the features, so
>>>>>>>>>>                          may be this is the problem.
>>>>>>>>>>
>>>>>>>>>>                          There isn't any clue in the "500 - Internal server
>>>>>>>>>>                          error" response to get what's happening, it should be in
>>>>>>>>>>                          the server log but the client doesn't get any hint.
>>>>>>>>>>
>>>>>>>>>>>                          I started to translate Kosmo into Finnish and I hope I
>>>>>>>>>>>                          will have somehow usable language file next week. Where
>>>>>>>>>>>                          can I send it when it is ready?
>>>>>>>>>>                          Great :). You can send it to me directly to my personal
>>>>>>>>>>                          mail and we add a new update to the download web page.
>>>>>>>>>>                          I'll need also the label you like to add to the
>>>>>>>>>>                          contributors page.
>>>>>>>>>>
>>>>>>>>>>                          Regards,
>>>>>>>>>>
>>>>>>>>>>                          El 10/03/2011 10:05, Rahkonen Jukka escribió:
>>>>>>>>>>>                          Hi, and thanks for the answers.
>>>>>>>>>>>                          Sergio Baños Calvo  wrote:
>>>>>>>>>>>
>>>>>>>>>>>                          >  I have tested your service (btw, thanks for it :) )
>>>>>>>>>>>                          >  and, after correcting some code in the WFS connector
>>>>>>>>>>>                          >  about XML parameters reading, I get to an
>>>>>>>>>>>                          >  "500 - Internal server error". Could you check if
>>>>>>>>>>>                          >  the server is working ok?
>>>>>>>>>>>                          GetFeature works for me both with WFS 1.0.0 and 1.1.0
>>>>>>>>>>>                          http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100
>>>>>>>>>>>                          <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100>
>>>>>>>>>>>                          and
>>>>>>>>>>>                          http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100
>>>>>>>>>>>                          <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100>
>>>>>>>>>>>                          GetCapabilities look good, as well as DescribeFeatureType
>>>>>>>>>>>                          http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point
>>>>>>>>>>>                          <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point>
>>>>>>>>>>>                          http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point
>>>>>>>>>>>                          <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point>
>>>>>>>>>>>                          I started to translate Kosmo into Finnish and I hope I
>>>>>>>>>>>                          will have somehow usable language file next week. Where
>>>>>>>>>>>                          can I send it when it is ready?
>>>>>>>>>>>                          -Jukka Rahkonen-
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                          _______________________________________________
>>>>>>>>>>>                          Kosmo_int mailing list
>>>>>>>>>>>                          [hidden email]
>>>>>>>>>>>                          http://lists.saig.es/mailman/listinfo/kosmo_int
>>>>>>>>>>                          --
>>>>>>>>>>
>>>>>>>>>>                          Sergio Baños Calvo
>>>>>>>>>>
>>>>>>>>>>                          Jefe de desarrollos
>>>>>>>>>>                          Sistemas Abiertos de Información Geográfica, S.L. (SAIG
>>>>>>>>>>                          S.L.)
>>>>>>>>>>                          Tlfno. móvil: 685005960
>>>>>>>>>>                          Tlfno. fijo: (+34) 954788876
>>>>>>>>>>
>>>>>>>>>>                          E-mail:[hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                      _______________________________________________
>>>>>>>>>>                      Kosmo_int mailing list
>>>>>>>>>>                      [hidden email]
>>>>>>>>>>                      http://lists.saig.es/mailman/listinfo/kosmo_int
>>>>>>>>>                      --
>>>>>>>>>
>>>>>>>>>                      Sergio Baños Calvo
>>>>>>>>>
>>>>>>>>>                      Jefe de desarrollos
>>>>>>>>>                      Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
>>>>>>>>>                      Tlfno. móvil: 685005960
>>>>>>>>>                      Tlfno. fijo: (+34) 954788876
>>>>>>>>>
>>>>>>>>>                      E-mail:[hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                  _______________________________________________
>>>>>>>>>                  Kosmo_int mailing list
>>>>>>>>>                  [hidden email]
>>>>>>>>>                  http://lists.saig.es/mailman/listinfo/kosmo_int
>>>>>>>>                  --
>>>>>>>>
>>>>>>>>                  Sergio Baños Calvo
>>>>>>>>
>>>>>>>>                  Jefe de desarrollos
>>>>>>>>                  Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
>>>>>>>>                  Tlfno. móvil: 685005960
>>>>>>>>                  Tlfno. fijo: (+34) 954788876
>>>>>>>>
>>>>>>>>                  E-mail:[hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>>             _______________________________________________
>>>>>>>>             Kosmo_int mailing list
>>>>>>>>             [hidden email]
>>>>>>>>             http://lists.saig.es/mailman/listinfo/kosmo_int
>>>>>>
>>>>>>             --
>>>>>>
>>>>>>             Sergio Baños Calvo
>>>>>>
>>>>>>             Jefe de desarrollos
>>>>>>             Sistemas Abiertos de Información Geográfica, S.L.
>>>>>>             (SAIG S.L.)
>>>>>>             Tlfno. móvil: 685005960
>>>>>>             Tlfno. fijo: (+34) 954788876
>>>>>>
>>>>>>             E-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>         _______________________________________________
>>>>>>         Kosmo_int mailing list
>>>>>>         [hidden email]
>>>>>>         http://lists.saig.es/mailman/listinfo/kosmo_int
>>>>>
>>>>>         --
>>>>>
>>>>>         Sergio Baños Calvo
>>>>>
>>>>>         Jefe de desarrollos
>>>>>         Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
>>>>>         Tlfno. móvil: 685005960
>>>>>         Tlfno. fijo: (+34) 954788876
>>>>>
>>>>>         E-mail: [hidden email]
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>         Kosmo_int mailing list
>>>>>         [hidden email]
>>>>>         http://lists.saig.es/mailman/listinfo/kosmo_int
>>>>
>>>>         --
>>>>
>>>>         Sergio Baños Calvo
>>>>
>>>>         Jefe de desarrollos
>>>>         Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
>>>>         Tlfno. móvil: 685005960
>>>>         Tlfno. fijo: (+34) 954788876
>>>>
>>>>         E-mail: [hidden email]
>>>>
>>>>
>>>>         _______________________________________________
>>>>         Kosmo_int mailing list
>>>>         [hidden email]
>>>>         http://lists.saig.es/mailman/listinfo/kosmo_int
>>>
>>>         --
>>>
>>>         Sergio Baños Calvo
>>>
>>>         Jefe de desarrollos
>>>         Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
>>>         Tlfno. móvil: 685005960
>>>         Tlfno. fijo: (+34) 954788876
>>>
>>>         E-mail: [hidden email]
>>>
>>>
>>>     _______________________________________________
>>>     Kosmo_int mailing list
>>>     [hidden email]
>>>     http://lists.saig.es/mailman/listinfo/kosmo_int
>>
>>     --
>>
>>     Sergio Baños Calvo
>>
>>     Jefe de desarrollos
>>     Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
>>     Tlfno. móvil: 685005960
>>     Tlfno. fijo: (+34) 954788876
>>
>>     E-mail: [hidden email]
>>
>>
>>     _______________________________________________
>>     Kosmo_int mailing list
>>     [hidden email]
>>     http://lists.saig.es/mailman/listinfo/kosmo_int
>
>     --
>
>     Sergio Baños Calvo
>
>     Jefe de desarrollos
>     Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
>     Tlfno. móvil: 685005960
>     Tlfno. fijo: (+34) 954788876
>
>     E-mail: [hidden email]
>
>
> _______________________________________________
> Kosmo_int mailing list
> [hidden email]
> http://lists.saig.es/mailman/listinfo/kosmo_int


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0

Marcel Spangenberg
In reply to this post by Sergio Baños Calvo
Hi Kosmo,
was it possible to get out of this mailing-list? I don't work with Kosmo and I'm just a bit lagged getting all these specific emails.
Merci for getting me out here and best wishes for your project.
M.


2011/5/19 Sergio Baños Calvo <[hidden email]>
Good afternoon, Jukka.

We finally decided to set the response reader charset to the one set at the request (utf-8): as you mentioned, the WFS response header is not reliable enough.

I have managed to build a developer update for Kosmo Desktop 2.0, you have it available at:

http://www.kosmoland.es/public/kosmo/v_2.0/binaries/kd_2.0_update_2011_05_19.zip

In order to install it, unzip the file and overwrite all the files at your Kosmo Desktop install directory. Remember that the changes are yet at developing stage and may contain bugs (I hope not ;)).

I have included a few more changes to the connector to improve usability:

1) When requesting the feature type schemas, a progress dialog is shown to let the user know the task progress.
2) In the attribute selection panel, if the feature type hasn't been correctly loaded or it doesn't contain a geometric attribute, it's disabled and won't be loaded afterwards.
3) In the attribute selection panel, it's possible to deselect a feature type and it won't be taken into account in the next panels (and it won't be loaded as a layer either)

Regards,

Hi,
 
I checked Geoserver version 2.1 rc2 on my own computer and deegree demo server at http://demo.deegree.org/deegree-wfs/services.  Both those are sending at least GetCapabilites response without having "charset=" in the headers.  Perhaps it is not very reliable to search the character encoding from WFS response headers.
 
-Jukka Rahkonen-


El 18/05/2011 15:42, Sergio Baños Calvo escribió:
Hi,

No problem about the previous reply ;).

I think i didn't explain myself correctly: TinyOWS is sending the response body correctly formated in UTF-8, but the response headers, that I used to set the charset for the request body reader, aren't filled correctly and the http client API can't get the charset from it, using ISO-8859-1 as returned value (the default one).

Comparing the two headers retrieved, seems that the IDEE WFS is adding "charset=UTF-8" to the request.

TinyOWS response headers:

Date: Wed, 18 May 2011 13:18:31 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/xml; subtype=gml/3.1.1


IDEE WFS response headers:

Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 18 May 2011 13:22:54 GMT


Anyway, it solved with the change I commented ;).

Regards,

El 18/05/2011 15:07, Rahkonen Jukka escribió:
Hi,
 
Sorry for the reply a minute ago without any comments.
First, I would really like to test the new client when it is possible.
 
Second, I will need to check the response headers.  However, I can see the encoding in the response body if I send this request with my browser
 
The result I am getting back begins with
 
<?xml version='1.0' encoding='UTF-8'?>
<wfs:FeatureCollection
 xmlns:tows='http://www.tinyows.org/'
 xmlns:lv='http://latuviitta.fi/'
 xmlns:wfs='http://www.opengis.net/wfs'
 
Perhaps that encoding information could be utilised?
 
I believe that with TinyOWS it will be wrong to believe that the result set is using the same encoding than the request. TinyOWS tells about a configuration parameter
encoding : OptionalOutput encoding. Default is UTF-8. Others values could be ISO-8859-1 for instance.
 
Thus I believe that if I set encoding to ISO-8859-1 it will be so even if I make request with UTF-8
 
-Jukka Rahkonen-
 
 


Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 18. toukokuuta 2011 15:49
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Hi,

Good news about the open issue: the connector have been improved again and it works now as expected:

[Image removed]

The problem with your TinyOWS is that, although I request it to send me the response in UTF-8, the response header doesn't contain any info about the response charset used (I have tested other servers, like the IDEE WFS server - http://www.idee.es/IDEE-WFS/ogcwebservice? -, and it fills the header correctly) and the http client takes ISO-8859-1 by default. So I have had to force the response reader to use the charset as if the server would always response as requested, and I have manage it to work that way.

I hope to have an update for testing tomorrow, if you like to test yourself.

Regards,

El 18/05/2011 9:32, Sergio Baños Calvo escribió:
Good morning Jukka.

The current WFS connector was using the first feature schema to build the layer schema, so that's the reason for the behaviour you commented in your mail. I have made some modifications to it in order to use the FeatureType schema instead, filtering out those attributes that have been unselected by the user, and it works right now :).

Respect to the filter issue, it's also related with the problem when reading the response from the server: it's not reading properly the response (sending the request). I will keep working on it today.

Regards,

El 17/05/2011 15:25, Sergio Baños Calvo escribió:
Hi, Jukka.

The osm_point layer works like a charm when removing the "tags" field, as you pointed in your previous mail.

Respect of the WFS reader, Kosmo Desktop WFS connector is based in OpenJUMP Degree WFS plugin. I'll check this afternoon the behaviour you're talking about with the lastest connector to see if the behaviour is the same after all the changes I'm doing to it.

The filter seems to be sent incorrectly, I'll check this also.

Regards,

El 17/05/2011 15:18, Rahkonen Jukka escribió:
Hi,
 
Some remarks on the WFS:
- Kosmo is using about the same WFS reader than gvSIG, or?  If yes, Kosmo may have same troubles than gvSIG (tested with version 1.11.0).
 
- Check the attribute table in Kosmo after doing GetFeature
 
Compare it with the layer schema
 
The resultset contains empty values for attribute "text3" and obviously therefore gvSIG builds an attribute table without that attribute.  The correct way would be to read the schema, make an empty table as an template and populate it then from the captured GML.
 
Also, I was not able to filter the "municipalities" feature type with a filter "kunta_ni1"='Saarijärvi'.  "kuknta_ni1"='Helsinki' does work, thus the error must be related to a non-ASCII character "ä".
 
-Jukka Rahkonen-
 
 


Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 13. toukokuuta 2011 13:30
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

Hi Jukka.

Seems that the server is sending the response correctly, so it's a problem in client side: I'll revise how the request response is read, seems that it's ignoring the charset and it's reading it incorrectly.

Regards,

El 13/05/2011 12:07, Rahkonen Jukka escribió:
Hi,

Great progress!  You are right, some characters do not look right. You can try to compare with this direct GetFeature

http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=municipalities&maxfeatures=1

Data comes from PostGIS and it is UTF8 there. Most common non-ASCII charaters are a-uml, o-uml and a-ring
"äöåÄÖÅ", if they now look OK even through this mail.

-Jukka-


-----Alkuperäinen viesti-----
Lähettäjä: [hidden email] puolesta: Sergio Baños Calvo
Lähetetty: pe 13.5.2011 13:02
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0
 
Hi Jukka.

I did some adjustments to the connector yesterday and I could manage to 
load the layers municipalities, osm_line and osm_polygon (the osm_point 
layer keeps giving me problems with some characters in the attributes 
when I request 1.000 or more features).

Here it's a capture of the layer "municipalities" loaded in Kosmo 
Desktop. Could you confirm me that the attribute data hasn't been 
correctly retrieved (seems that some of the characters hasn't been read 
correctly in the fields "suural_ni1", "suural_ni2", "avi_n1" and "avi_n2")?

tinyows_municipalities


Regards,

El 12/05/2011 15:33, Rahkonen Jukka escribió:
Hi,
There may well be data errors in my current feature types because the 
OpenStreetMap data do not always convert easily into simple features 
and GML.  I have corrected some most obvious issues like renaming 
attributes like addr:housenumber into addr_housenumber but I am not 
surprised if there are some errors left. I should really add some more 
conventional feature types into the service and include other types of 
attributes than just strings.
I look forward to get my hands on your development version.
-Jukka Rahkonen-

    ------------------------------------------------------------------------
    *Lähettäjä:* [hidden email]
    [[hidden email]] *Puolesta *Sergio Baños Calvo
    *Lähetetty:* 12. toukokuuta 2011 16:23
    *Vastaanottaja:* International Kosmo mailing list (english languaje)
    *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

    Hi again Jukka.

    No problem for Kosmo Desktop, it's processing the operations in
    both ways, so the POST url (the one that uses Kosmo Desktop for
    connecting to the server) is being taken correctly (in the current
    development version, that error is present at the 2.0 official
    version).

    I have made some more testings in your server instance and seems
    that the connector is not retrieving properly some of the features
    from the server (it's giving errors when parsing the response when
    requesting 1.000 features). I'll keep you informed about any advances.

    Regards,

    El 12/05/2011 15:08, Rahkonen Jukka escribió:
    Hi,
    I may have found something new today, it is about how TinyOWS is
    listing the URLs for GetFeature in http GET vs. POST.  I have
    asked about is from deegree and TinyOWS user lists.  I believe
    you should check it as well. TinyOWS is announcing the GET and
    POST URLs in two separate ows:DCP elements while deegree and
    Geoserver are listing them as a list in one DCP element. I
    suspect that because of this OpenJUMP WFS plugin and iGeoDesktop
    do not find the Post URL at all.
    This is from deegree WFS
    <ows:OperationsMetadata xmlns="http://www.opengis.net/ows">
    <ows:Operation xmlns="http://www.opengis.net/ows" name="GetFeature">
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Get xmlns="http://www.opengis.net/ows"
    xlink:href="http://demo.deegree.org:80/deegree-wfs/services?"
    xlink:type="simple"></ows:Get>
    <ows:Post xmlns="http://www.opengis.net/ows"
    xlink:href="http://demo.deegree.org:80/deegree-wfs/services"
    xlink:type="simple"></ows:Post>
    </ows:HTTP>
    </ows:DCP>
    </ows:Operation>

    This is from TinyOWS
    <ows:Operation xmlns="http://www.opengis.net/ows" name="GetFeature">
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Get xmlns="http://www.opengis.net/ows"
    xlink:href="http://188.64.1.61/cgi-bin/tinyows?"></ows:Get
    <http://188.64.1.61/cgi-bin/tinyows?%22%3E%3C/ows:Get>>
    </ows:HTTP>
    </ows:DCP>
    <ows:DCP xmlns="http://www.opengis.net/ows">
    <ows:HTTP xmlns="http://www.opengis.net/ows">
    <ows:Post xmlns="http://www.opengis.net/ows"
    xlink:href="http://188.64.1.61/cgi-bin/tinyows"></ows:Post
    <http://188.64.1.61/cgi-bin/tinyows%22%3E%3C/ows:Post>>
    </ows:HTTP>
    </ows:DCP>
    -Jukka Rahkonen-


        ------------------------------------------------------------------------
        *Lähettäjä:* [hidden email]
        [[hidden email]] *Puolesta *Sergio Baños Calvo
        *Lähetetty:* 12. toukokuuta 2011 16:00
        *Vastaanottaja:* International Kosmo mailing list (english
        languaje)
        *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

        Hi Jukka.

        Thank you very much for your assistance.

        I did some modifications to the WFS connector the first time
        but I didn't manage to connect to your old TinyOWS instance.

        I have made some testing over your new TinyOWS server and,
        after some adjustments to the WFS connector, I have finally
        got some data from it. The clue about the problem was given
        for a post made by you at the TinyOWS list (in this case the
        TinyOWS server response wasn't an internal server error like
        the last time, but a wrong content-type header exception):

        http://lists.maptools.org/pipermail/tinyows-users/2010-September/000193.html

        I'll try to generate a development version for testing in the
        next few days.

        Regards,

        El 12/05/2011 12:51, Rahkonen Jukka escribió:
        Hi,
        I sent some observations about Kosmo as a WFS client fot the
        TinyOWS server two months ago. Now I have updated my TinyOWS
        server into version 1.0 rc1 which is supposed to pass all
        the CITE WFS tests for both WFS 1.0.0 and 1.1.0. 
        Unfortunately after this update Kosmo does not get any
        further than reading the GetCapabilities and
        DescribeFeatureType.
        If you happen to have some development versions about the
        WFS client available I would be happy to do some testing. My
        WFS server is also open for you and it is still found at
        http://188.64.1.61/cgi-bin/tinyows?
        Regards,
        -Jukka Rahkonen-
        ------------------------------------------------------------------------
        *Lähettäjä:* [hidden email]
        [[hidden email]] *Puolesta *Sergio Baños Calvo
        *Lähetetty:* 10. maaliskuuta 2011 13:14
        *Vastaanottaja:* International Kosmo mailing list (english
        languaje)
        *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

            Hi again Jukka.

            Yes, the GetCapabilities and DescribeFeatureType
            requests works ok, but the problema arises when the
            GetFeature request is sent: as you mention in your next
            mail, Kosmo Desktop uses POST to get the features, so
            may be this is the problem.

            There isn't any clue in the "500 - Internal server
            error" response to get what's happening, it should be in
            the server log but the client doesn't get any hint.

            I started to translate Kosmo into Finnish and I hope I
            will have somehow usable language file next week. Where
            can I send it when it is ready?
            Great :). You can send it to me directly to my personal
            mail and we add a new update to the download web page.
            I'll need also the label you like to add to the
            contributors page.

            Regards,

            El 10/03/2011 10:05, Rahkonen Jukka escribió:
            Hi, and thanks for the answers.
            Sergio Baños Calvo  wrote:

            > I have tested your service (btw, thanks for it :) )
            > and, after correcting some code in the WFS connector
            > about XML parameters reading, I get to an
            > "500 - Internal server error". Could you check if
            > the server is working ok?
            GetFeature works for me both with WFS 1.0.0 and 1.1.0
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100>
            and
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100>
            GetCapabilities look good, as well as DescribeFeatureType
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point>
            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point
            <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point>
            I started to translate Kosmo into Finnish and I hope I
            will have somehow usable language file next week. Where
            can I send it when it is ready?
            -Jukka Rahkonen-


            _______________________________________________
            Kosmo_int mailing list
            [hidden email]
            http://lists.saig.es/mailman/listinfo/kosmo_int
            -- 

            Sergio Baños Calvo

            Jefe de desarrollos
            Sistemas Abiertos de Información Geográfica, S.L. (SAIG
            S.L.)
            Tlfno. móvil: 685005960
            Tlfno. fijo: (+34) 954788876

            E-mail: [hidden email]


        _______________________________________________
        Kosmo_int mailing list
        [hidden email]
        http://lists.saig.es/mailman/listinfo/kosmo_int
        -- 

        Sergio Baños Calvo

        Jefe de desarrollos
        Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
        Tlfno. móvil: 685005960
        Tlfno. fijo: (+34) 954788876

        E-mail: [hidden email]


    _______________________________________________
    Kosmo_int mailing list
    [hidden email]
    http://lists.saig.es/mailman/listinfo/kosmo_int
    -- 

    Sergio Baños Calvo

    Jefe de desarrollos
    Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
    Tlfno. móvil: 685005960
    Tlfno. fijo: (+34) 954788876

    E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int




--
--------------------------------------------------
Marcel  Spangenberg
Seltersweg 69
35390 Gießen
Deutschland
+49176-35776630
skype:marcel.spangenberg
http://geo-linguistique.bplaced.net/
www.geographiesansfrontieres.org




_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Unsubscribe from Kosmo International mailing list

Sergio Baños Calvo
Good morning Marcel.

You can unsubscribe through the form present at the next URL (it's at the bottom of all the mails):

http://lists.saig.es/mailman/listinfo/kosmo_int

Regards,

El 20/05/2011 9:14, Marcel Spangenberg escribió:
Hi Kosmo,
was it possible to get out of this mailing-list? I don't work with Kosmo and I'm just a bit lagged getting all these specific emails.
Merci for getting me out here and best wishes for your project.
M.



--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0

Sergio Baños Calvo
In reply to this post by Rahkonen Jukka
Hi,

I have revised the behaviour of the WFS connector against the 1.0.0 and the GetFeature request was not properly build. I have changed it in order to take into account the exact WFS version that we're using to connect and now it works as expected.

You have a new development update at:

http://www.kosmoland.es/public/kosmo/v_2.0/binaries/kd_2.0_update_2011_05_20.zip

Have you give a try to the spatial filters? A hint: you can select a geometry before using the WFS wizard to use it as base (as it is, or buffering it) to your spatial queries. Just press the "..." button at the filter wizard and it will ask you a distance to use.

Respect to a new Kosmo Desktop release, we use to make only big releases, but this way to work is going to be changed soon, so we can plan a new minor update (for the next week, probably).

Regards,


El 19/05/2011 21:09, Rahkonen Jukka escribió:
Hi,

The develompent WFS works extraordinary well with TinyOWS and WFS 1.1.0. I believe that proxy had nothing to do with my problems but it was because I used the default WFS version 1.0.0. and with that version the final GetFeatures are failing.  

I haven't tried spatial filters yet but plain GetFeatures and attribute filters seem to work very well against my TinyOWS. Even the non-ASCII characters can be used in filter, and filters with OR work as well. Pretty well done, thanks!

Are you planning to make some minory release of Kosmo that would include these WFS enhancements sometimes soon?

-Jukka Rahkonen-


-----Alkuperäinen viesti-----
Lähettäjä: [hidden email] puolesta: Sergio Baños Calvo
Lähetetty: to 19.5.2011 18:51
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0
 
Hi Jukka.

If you configured the proxy settings at configuration dialog, it should 
use them, but may be we've missed them in the last step.

I'll check it later.

Regards,

El 19/05/2011 16:35, Rahkonen Jukka escribió:
Hi,
I installed the developer update but I didn't manage to read features 
yet.  WFS driver is connecting with our WFS and a few others I tried, 
but somehow it looks like it does not send at all the final http POST 
GetFeature.  I was trying also the preconfigured services like 
IDEE-WFS.  GetCapabilities and DescribeFeatureType are successful but 
after GetFeature I am getting this error I get is: Error when making 
connection with 
server:http://www.idee.es/IDEE-WFS/ogcwebservice. Connection time out: 
connect.  Web traffic crawler does not capture anything so it looks 
like Kosmo does not manage to send the GetFeature at all.
I will have a try at home with direct internet connection and check if 
this has something to do with proxy.
Regards,
-Jukka Rahkonen-
------------------------------------------------------------------------
*Lähettäjä:* [hidden email] 
[[hidden email]] *Puolesta *Sergio Baños Calvo
*Lähetetty:* 19. toukokuuta 2011 17:04
*Vastaanottaja:* International Kosmo mailing list (english languaje)
*Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

    Good afternoon, Jukka.

    We finally decided to set the response reader charset to the one
    set at the request (utf-8): as you mentioned, the WFS response
    header is not reliable enough.

    I have managed to build a developer update for Kosmo Desktop 2.0,
    you have it available at:

    http://www.kosmoland.es/public/kosmo/v_2.0/binaries/kd_2.0_update_2011_05_19.zip

    In order to install it, unzip the file and overwrite all the files
    at your Kosmo Desktop install directory. Remember that the changes
    are yet at developing stage and may contain bugs (I hope not ;)).

    I have included a few more changes to the connector to improve
    usability:

    1) When requesting the feature type schemas, a progress dialog is
    shown to let the user know the task progress.
    2) In the attribute selection panel, if the feature type hasn't
    been correctly loaded or it doesn't contain a geometric attribute,
    it's disabled and won't be loaded afterwards.
    3) In the attribute selection panel, it's possible to deselect a
    feature type and it won't be taken into account in the next panels
    (and it won't be loaded as a layer either)

    Regards,

    Hi,
    I checked Geoserver version 2.1 rc2 on my own computer and
    deegree demo server at
    http://demo.deegree.org/deegree-wfs/services.  Both those are
    sending at least GetCapabilites response without having
    "charset=" in the headers.  Perhaps it is not very reliable to
    search the character encoding from WFS response headers.
    -Jukka Rahkonen-

    El 18/05/2011 15:42, Sergio Baños Calvo escribió:
    Hi,

    No problem about the previous reply ;).

    I think i didn't explain myself correctly: TinyOWS is sending the
    response body correctly formated in UTF-8, but the response
    headers, that I used to set the charset for the request body
    reader, aren't filled correctly and the http client API can't get
    the charset from it, using ISO-8859-1 as returned value (the
    default one).

    Comparing the two headers retrieved, seems that the IDEE WFS is
    adding "charset=UTF-8" to the request.

    TinyOWS response headers:

    Date: Wed, 18 May 2011 13:18:31 GMT
    Server: Apache/2.2.14 (Ubuntu)
    Vary: Accept-Encoding
    Transfer-Encoding: chunked
    Content-Type: text/xml; subtype=gml/3.1.1


    IDEE WFS response headers:

    Server: Apache-Coyote/1.1
    Content-Type: text/xml;charset=UTF-8
    Transfer-Encoding: chunked
    Date: Wed, 18 May 2011 13:22:54 GMT


    Anyway, it solved with the change I commented ;).

    Regards,

    El 18/05/2011 15:07, Rahkonen Jukka escribió:
    Hi,
    Sorry for the reply a minute ago without any comments.
    First, I would really like to test the new client when it is
    possible.
    Second, I will need to check the response headers.  However, I
    can see the encoding in the response body if I send this request
    with my browser
    http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=municipalities&maxfeatures=2
    <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=municipalities&maxfeatures=2>
    The result I am getting back begins with
    <?xml version='1.0' encoding='UTF-8'?>
    <wfs:FeatureCollection
     xmlns:tows='http://www.tinyows.org/'
     xmlns:lv='http://latuviitta.fi/'
     xmlns:wfs='http://www.opengis.net/wfs'
    Perhaps that encoding information could be utilised?
    I believe that with TinyOWS it will be wrong to believe that the
    result set is using the same encoding than the request. TinyOWS
    tells about a configuration parameter
    encoding : OptionalOutput encoding. Default is UTF-8. Others
    values could be ISO-8859-1 for instance.
    Thus I believe that if I set encoding to ISO-8859-1 it will be
    so even if I make request with UTF-8
    -Jukka Rahkonen-

        ------------------------------------------------------------------------
        *Lähettäjä:* [hidden email]
        [[hidden email]] *Puolesta *Sergio Baños Calvo
        *Lähetetty:* 18. toukokuuta 2011 15:49
        *Vastaanottaja:* International Kosmo mailing list (english
        languaje)
        *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

        Hi,

        Good news about the open issue: the connector have been
        improved again and it works now as expected:

        [Image removed]

        The problem with your TinyOWS is that, although I request it
        to send me the response in UTF-8, the response header
        doesn't contain any info about the response charset used (I
        have tested other servers, like the IDEE WFS server -
        http://www.idee.es/IDEE-WFS/ogcwebservice? -, and it fills
        the header correctly) and the http client takes ISO-8859-1
        by default. So I have had to force the response reader to
        use the charset as if the server would always response as
        requested, and I have manage it to work that way.

        I hope to have an update for testing tomorrow, if you like
        to test yourself.

        Regards,

        El 18/05/2011 9:32, Sergio Baños Calvo escribió:
        Good morning Jukka.

        The current WFS connector was using the first feature
        schema to build the layer schema, so that's the reason for
        the behaviour you commented in your mail. I have made some
        modifications to it in order to use the FeatureType schema
        instead, filtering out those attributes that have been
        unselected by the user, and it works right now :).

        Respect to the filter issue, it's also related with the
        problem when reading the response from the server: it's not
        reading properly the response (sending the request). I will
        keep working on it today.

        Regards,

        El 17/05/2011 15:25, Sergio Baños Calvo escribió:
        Hi, Jukka.

        The osm_point layer works like a charm when removing the
        "tags" field, as you pointed in your previous mail.

        Respect of the WFS reader, Kosmo Desktop WFS connector is
        based in OpenJUMP Degree WFS plugin. I'll check this
        afternoon the behaviour you're talking about with the
        lastest connector to see if the behaviour is the same
        after all the changes I'm doing to it.

        The filter seems to be sent incorrectly, I'll check this also.

        Regards,

        El 17/05/2011 15:18, Rahkonen Jukka escribió:
        Hi,
        Some remarks on the WFS:
        - Kosmo is using about the same WFS reader than gvSIG,
        or?  If yes, Kosmo may have same troubles than gvSIG
        (tested with version 1.11.0).
        - Check the attribute table in Kosmo after doing GetFeature
        http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=lv:mml_cityp&maxfeatures=10
        <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=lv:mml_cityp&maxfeatures=10>
        Compare it with the layer schema
        http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=lv:mml_cityp
        <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=lv:mml_cityp>
        The resultset contains empty values for attribute "text3"
        and obviously therefore gvSIG builds an attribute table
        without that attribute.  The correct way would be to read
        the schema, make an empty table as an template and
        populate it then from the captured GML.
        Also, I was not able to filter the "municipalities"
        feature type with a filter "kunta_ni1"='Saarijärvi'. 
        "kuknta_ni1"='Helsinki' does work, thus the error must be
        related to a non-ASCII character "ä".
        -Jukka Rahkonen-

            ------------------------------------------------------------------------
            *Lähettäjä:* [hidden email]
            [[hidden email]] *Puolesta *Sergio
            Baños Calvo
            *Lähetetty:* 13. toukokuuta 2011 13:30
            *Vastaanottaja:* International Kosmo mailing list
            (english languaje)
            *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

            Hi Jukka.

            Seems that the server is sending the response
            correctly, so it's a problem in client side: I'll
            revise how the request response is read, seems that
            it's ignoring the charset and it's reading it
            incorrectly.

            Regards,

            El 13/05/2011 12:07, Rahkonen Jukka escribió:
            Hi,

            Great progress!  You are right, some characters do not look right. You can try to compare with this direct GetFeature

            http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=municipalities&maxfeatures=1

            Data comes from PostGIS and it is UTF8 there. Most common non-ASCII charaters are a-uml, o-uml and a-ring
            "äöåÄÖÅ", if they now look OK even through this mail.

            -Jukka-


            -----Alkuperäinen viesti-----
            Lähettäjä:[hidden email]  puolesta: Sergio Baños Calvo
            Lähetetty: pe 13.5.2011 13:02
            Vastaanottaja: International Kosmo mailing list (english languaje)
            Aihe: Re: [Kosmo_int] Testing Kosmo 2.0

            Hi Jukka.

            I did some adjustments to the connector yesterday and I could manage to
            load the layers municipalities, osm_line and osm_polygon (the osm_point
            layer keeps giving me problems with some characters in the attributes
            when I request 1.000 or more features).

            Here it's a capture of the layer "municipalities" loaded in Kosmo
            Desktop. Could you confirm me that the attribute data hasn't been
            correctly retrieved (seems that some of the characters hasn't been read
            correctly in the fields "suural_ni1", "suural_ni2", "avi_n1" and "avi_n2")?

            tinyows_municipalities


            Regards,

            El 12/05/2011 15:33, Rahkonen Jukka escribió:
            Hi,
            There may well be data errors in my current feature types because the
            OpenStreetMap data do not always convert easily into simple features
            and GML.  I have corrected some most obvious issues like renaming
            attributes like addr:housenumber into addr_housenumber but I am not
            surprised if there are some errors left. I should really add some more
            conventional feature types into the service and include other types of
            attributes than just strings.
            I look forward to get my hands on your development version.
            -Jukka Rahkonen-

                 ------------------------------------------------------------------------
                 *Lähettäjä:*[hidden email]
                 [[hidden email]] *Puolesta *Sergio Baños Calvo
                 *Lähetetty:* 12. toukokuuta 2011 16:23
                 *Vastaanottaja:* International Kosmo mailing list (english languaje)
                 *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

                 Hi again Jukka.

                 No problem for Kosmo Desktop, it's processing the operations in
                 both ways, so the POST url (the one that uses Kosmo Desktop for
                 connecting to the server) is being taken correctly (in the current
                 development version, that error is present at the 2.0 official
                 version).

                 I have made some more testings in your server instance and seems
                 that the connector is not retrieving properly some of the features
                 from the server (it's giving errors when parsing the response when
                 requesting 1.000 features). I'll keep you informed about any advances.

                 Regards,

                 El 12/05/2011 15:08, Rahkonen Jukka escribió:
                 Hi,
                 I may have found something new today, it is about how TinyOWS is
                 listing the URLs for GetFeature in http GET vs. POST.  I have
                 asked about is from deegree and TinyOWS user lists.  I believe
                 you should check it as well. TinyOWS is announcing the GET and
                 POST URLs in two separate ows:DCP elements while deegree and
                 Geoserver are listing them as a list in one DCP element. I
                 suspect that because of this OpenJUMP WFS plugin and iGeoDesktop
                 do not find the Post URL at all.
                 This is from deegree WFS
                 <ows:OperationsMetadata xmlns="http://www.opengis.net/ows">
                 <ows:Operation xmlns="http://www.opengis.net/ows"  name="GetFeature">
                 <ows:DCP xmlns="http://www.opengis.net/ows">
                 <ows:HTTP xmlns="http://www.opengis.net/ows">
                 <ows:Get xmlns="http://www.opengis.net/ows"
                 xlink:href="http://demo.deegree.org:80/deegree-wfs/services?"
                 xlink:type="simple"></ows:Get>
                 <ows:Post xmlns="http://www.opengis.net/ows"
                 xlink:href="http://demo.deegree.org:80/deegree-wfs/services"
                 xlink:type="simple"></ows:Post>
                 </ows:HTTP>
                 </ows:DCP>
                 </ows:Operation>

                 This is from TinyOWS
                 <ows:Operation xmlns="http://www.opengis.net/ows"  name="GetFeature">
                 <ows:DCP xmlns="http://www.opengis.net/ows">
                 <ows:HTTP xmlns="http://www.opengis.net/ows">
                 <ows:Get xmlns="http://www.opengis.net/ows"
                 xlink:href="http://188.64.1.61/cgi-bin/tinyows?"></ows:Get
                 <http://188.64.1.61/cgi-bin/tinyows?%22%3E%3C/ows:Get>>
                 </ows:HTTP>
                 </ows:DCP>
                 <ows:DCP xmlns="http://www.opengis.net/ows">
                 <ows:HTTP xmlns="http://www.opengis.net/ows">
                 <ows:Post xmlns="http://www.opengis.net/ows"
                 xlink:href="http://188.64.1.61/cgi-bin/tinyows"></ows:Post
                 <http://188.64.1.61/cgi-bin/tinyows%22%3E%3C/ows:Post>>
                 </ows:HTTP>
                 </ows:DCP>
                 -Jukka Rahkonen-


                     ------------------------------------------------------------------------
                     *Lähettäjä:*[hidden email]
                     [[hidden email]] *Puolesta *Sergio Baños Calvo
                     *Lähetetty:* 12. toukokuuta 2011 16:00
                     *Vastaanottaja:* International Kosmo mailing list (english
                     languaje)
                     *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

                     Hi Jukka.

                     Thank you very much for your assistance.

                     I did some modifications to the WFS connector the first time
                     but I didn't manage to connect to your old TinyOWS instance.

                     I have made some testing over your new TinyOWS server and,
                     after some adjustments to the WFS connector, I have finally
                     got some data from it. The clue about the problem was given
                     for a post made by you at the TinyOWS list (in this case the
                     TinyOWS server response wasn't an internal server error like
                     the last time, but a wrong content-type header exception):

                     http://lists.maptools.org/pipermail/tinyows-users/2010-September/000193.html

                     I'll try to generate a development version for testing in the
                     next few days.

                     Regards,

                     El 12/05/2011 12:51, Rahkonen Jukka escribió:
                     Hi,
                     I sent some observations about Kosmo as a WFS client fot the
                     TinyOWS server two months ago. Now I have updated my TinyOWS
                     server into version 1.0 rc1 which is supposed to pass all
                     the CITE WFS tests for both WFS 1.0.0 and 1.1.0.
                     Unfortunately after this update Kosmo does not get any
                     further than reading the GetCapabilities and
                     DescribeFeatureType.
                     If you happen to have some development versions about the
                     WFS client available I would be happy to do some testing. My
                     WFS server is also open for you and it is still found at
                     http://188.64.1.61/cgi-bin/tinyows?
                     Regards,
                     -Jukka Rahkonen-
                     ------------------------------------------------------------------------
                     *Lähettäjä:*[hidden email]
                     [[hidden email]] *Puolesta *Sergio Baños Calvo
                     *Lähetetty:* 10. maaliskuuta 2011 13:14
                     *Vastaanottaja:* International Kosmo mailing list (english
                     languaje)
                     *Aihe:* Re: [Kosmo_int] Testing Kosmo 2.0

                         Hi again Jukka.

                         Yes, the GetCapabilities and DescribeFeatureType
                         requests works ok, but the problema arises when the
                         GetFeature request is sent: as you mention in your next
                         mail, Kosmo Desktop uses POST to get the features, so
                         may be this is the problem.

                         There isn't any clue in the "500 - Internal server
                         error" response to get what's happening, it should be in
                         the server log but the client doesn't get any hint.

                         I started to translate Kosmo into Finnish and I hope I
                         will have somehow usable language file next week. Where
                         can I send it when it is ready?
                         Great :). You can send it to me directly to my personal
                         mail and we add a new update to the download web page.
                         I'll need also the label you like to add to the
                         contributors page.

                         Regards,

                         El 10/03/2011 10:05, Rahkonen Jukka escribió:
                         Hi, and thanks for the answers.
                         Sergio Baños Calvo  wrote:

                         >  I have tested your service (btw, thanks for it :) )
                         >  and, after correcting some code in the WFS connector
                         >  about XML parameters reading, I get to an
                         >  "500 - Internal server error". Could you check if
                         >  the server is working ok?
                         GetFeature works for me both with WFS 1.0.0 and 1.1.0
                         http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100
                         <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=getfeature&typename=osm_point&maxfeatures=100>
                         and
                         http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100
                         <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=getfeature&typename=osm_point&maxfeatures=100>
                         GetCapabilities look good, as well as DescribeFeatureType
                         http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point
                         <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=describefeaturetype&typename=osm_point>
                         http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point
                         <http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.1.0&request=describefeaturetype&typename=osm_point>
                         I started to translate Kosmo into Finnish and I hope I
                         will have somehow usable language file next week. Where
                         can I send it when it is ready?
                         -Jukka Rahkonen-


                         _______________________________________________
                         Kosmo_int mailing list
                         [hidden email]
                         http://lists.saig.es/mailman/listinfo/kosmo_int
                         -- 

                         Sergio Baños Calvo

                         Jefe de desarrollos
                         Sistemas Abiertos de Información Geográfica, S.L. (SAIG
                         S.L.)
                         Tlfno. móvil: 685005960
                         Tlfno. fijo: (+34) 954788876

                         [hidden email]


                     _______________________________________________
                     Kosmo_int mailing list
                     [hidden email]
                     http://lists.saig.es/mailman/listinfo/kosmo_int
                     -- 

                     Sergio Baños Calvo

                     Jefe de desarrollos
                     Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
                     Tlfno. móvil: 685005960
                     Tlfno. fijo: (+34) 954788876

                     [hidden email]


                 _______________________________________________
                 Kosmo_int mailing list
                 [hidden email]
                 http://lists.saig.es/mailman/listinfo/kosmo_int
                 -- 

                 Sergio Baños Calvo

                 Jefe de desarrollos
                 Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
                 Tlfno. móvil: 685005960
                 Tlfno. fijo: (+34) 954788876

                 [hidden email]


            _______________________________________________
            Kosmo_int mailing list
            [hidden email]
            http://lists.saig.es/mailman/listinfo/kosmo_int
            -- 

            Sergio Baños Calvo

            Jefe de desarrollos
            Sistemas Abiertos de Información Geográfica, S.L.
            (SAIG S.L.)
            Tlfno. móvil: 685005960
            Tlfno. fijo: (+34) 954788876

            E-mail: [hidden email]


        _______________________________________________
        Kosmo_int mailing list
        [hidden email]
        http://lists.saig.es/mailman/listinfo/kosmo_int
        -- 

        Sergio Baños Calvo

        Jefe de desarrollos
        Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
        Tlfno. móvil: 685005960
        Tlfno. fijo: (+34) 954788876

        E-mail: [hidden email]


        _______________________________________________
        Kosmo_int mailing list
        [hidden email]
        http://lists.saig.es/mailman/listinfo/kosmo_int
        -- 

        Sergio Baños Calvo

        Jefe de desarrollos
        Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
        Tlfno. móvil: 685005960
        Tlfno. fijo: (+34) 954788876

        E-mail: [hidden email]


        _______________________________________________
        Kosmo_int mailing list
        [hidden email]
        http://lists.saig.es/mailman/listinfo/kosmo_int
        -- 

        Sergio Baños Calvo

        Jefe de desarrollos
        Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
        Tlfno. móvil: 685005960
        Tlfno. fijo: (+34) 954788876

        E-mail: [hidden email]


    _______________________________________________
    Kosmo_int mailing list
    [hidden email]
    http://lists.saig.es/mailman/listinfo/kosmo_int
    -- 

    Sergio Baños Calvo

    Jefe de desarrollos
    Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
    Tlfno. móvil: 685005960
    Tlfno. fijo: (+34) 954788876

    E-mail: [hidden email]


    _______________________________________________
    Kosmo_int mailing list
    [hidden email]
    http://lists.saig.es/mailman/listinfo/kosmo_int
    -- 

    Sergio Baños Calvo

    Jefe de desarrollos
    Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
    Tlfno. móvil: 685005960
    Tlfno. fijo: (+34) 954788876

    E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int

_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int


--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Testing Kosmo 2.0 WFS

Rahkonen Jukka
In reply to this post by Rahkonen Jukka
 
Hi,

I received your mail just after I had decided to stop the old long
thread and start a new one with a better describing title.

I answer first to your questions, and below will follow the mail I had
prepered for sending earlier.

" I have revised the behaviour of the WFS connector against the 1.0.0
and the GetFeature request was not properly build. I have changed it in
order to take into account the exact WFS version that we're using to
connect and now it works as expected."

Yes, a new version can read features with WFS 1.0.0.  Spatial filters do
not work and you can read more about it later in this mail

" Have you give a try to the spatial filters? "
Yes, read more below.

" we can plan a new minor update (for the next week, probably)."
Very much appreciated even if there would be some minory things left.
Finnish language file and improved WFS would be valuable for us.

And here are my comments after testing the yesterdays version.

The developer version of WFS which I received yesterday is definitely
having troubles with proxy. It is sending the final GetFeature as http
POST directly to the destination URL and not to the proxy server. I did
not notice that at home because even I use Fiddler software as a
debugging proxy the direct connection is not blocked.
The developer version is having some issues but I cannot investigate
them now pretty well myself because due to the proxy problem I cannot
capture the critical requests and theis headers. It would be nice to get
another version with a proxy fix some day. Now I can only report about
how the four issues (A, B, C and D) which I have found this far appear.

A) Kosmo is creating faulty WFS 1.1.0 spatial filters for polygons. Here
is one filter created by Kosmo
<ogc:Filter><ogc:Intersects>
<ogc:PropertyName>lv:the_geom</ogc:PropertyName>
<gml:Surface>
<gml:patches>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>369599.4780422082 6919973.386401318 369599.4780422082
6980714.097399444 448217.05381570297 6980714.097399444
448217.05381570297 6919973.386401318 369599.4780422082 6919973.386401318
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:patches>
</gml:Surface>

Schema validating TinyOWS says that <gml:Polygon> is illegal and it
should be <gml:PolygonPatch> instead. I do not know that for sure but
these links http://jira.codehaus.org/browse/GEOS-2868 and
http://jira.codehaus.org/secure/attachment/41559/WFS1.1_correct_surface_
request.txt are handling a little bit similar case. The latter lind
shows a filter that was created by OpenJUMP WFS plugin and it is using
PolygonPatch.

Geoserver seems to be merciful and in my test with Geoserver 2.1 it did
accept the Kosmo filter with <gml:Polygon>.

B) For some reason the developer WFS read my TinyWFS only with WFS
version 1.0.0. The two TinyOWS errors I can see in the log are
[ERROR] Element '{http://www.opengis.net/wfs}Query', attribute
'srsName': The attribute 'srsName' is not allowed.
and
[ERROR] Element '{http://www.opengis.net/wfs}PropertyName': This element
is not expected. Expected is one of (
{http://www.opengis.net/ogc}PropertyName,
{http://www.opengis.net/ogc}Filter ).

I am thinking that TinyOWS is too strict with the additional srsName
element because even it is not supported by WFS 1.0.0 standart still
TinyOWS itself supports the use of srsName in GET requests as you can
test by this
http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&request=get
feature&typename=osm_polygon&maxfeatures=20&srsName=EPSG:4326

I can't say anything about the difference of wfs PropertyName and ogc
PropertyName. I will ask about that from TinyOWS side.

C) Kosmo reads our feature types coming Geoserver 2.1 fine with WFS
version 1.0.0 so Geoserver is not suffering from the issues of the case
B) above. However, if I make GetFeature requests with WFS 1.1.0 I am
always getting just one single feature drawn on the Kosmo map. I could
verify this behaviour by making a totally new Geoserver v. 2.1
installation and using the Geoserver demo feature types for testing. The
request that is sent by Kosmo is OK with maxFeatures=1000 and I do
believe that Geoserver WFS is really sending more features but Kosmo is
just parsing the first feature.

D) Spatial filters with WFS 1.0.0 do not work. If you have not done a
big rewrite for the OpenJUMP WFS plugin version 1.1 I am not surprised
about it. After the latest modifications into OpenJUMP WFS plugin it
started to create WFS 1.1.0 style spatial filters even when version
1.0.0 is selected. Evidently the developers were not playing with WFS
1.0.0 any more and they did not care even they broke the 1.0.0 support.

Regards,

-Jukka Rahkonen-
_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0 WFS

Rahkonen Jukka
Hi,

I have one simple question: Why Kosmo WFS does not support spatial
filter DWithin? Is it just for avoiding repetition because the same
effect obviously can be achieved by using the Intersects filter with a
buffer?

-Jukka Rahkonen-

Rahkonen Jukka wrote:

 

> Hi,
>
> I received your mail just after I had decided to stop the old long
> thread and start a new one with a better describing title.
>
> I answer first to your questions, and below will follow the mail I had
> prepered for sending earlier.
>
> " I have revised the behaviour of the WFS connector against the 1.0.0
> and the GetFeature request was not properly build. I have
> changed it in
> order to take into account the exact WFS version that we're using to
> connect and now it works as expected."
>
> Yes, a new version can read features with WFS 1.0.0.  Spatial
> filters do
> not work and you can read more about it later in this mail
>
> " Have you give a try to the spatial filters? "
> Yes, read more below.
>
> " we can plan a new minor update (for the next week, probably)."
> Very much appreciated even if there would be some minory things left.
> Finnish language file and improved WFS would be valuable for us.
>
> And here are my comments after testing the yesterdays version.
>
> The developer version of WFS which I received yesterday is definitely
> having troubles with proxy. It is sending the final GetFeature as http
> POST directly to the destination URL and not to the proxy
> server. I did
> not notice that at home because even I use Fiddler software as a
> debugging proxy the direct connection is not blocked.
> The developer version is having some issues but I cannot investigate
> them now pretty well myself because due to the proxy problem I cannot
> capture the critical requests and theis headers. It would be
> nice to get
> another version with a proxy fix some day. Now I can only report about
> how the four issues (A, B, C and D) which I have found this
> far appear.
>
> A) Kosmo is creating faulty WFS 1.1.0 spatial filters for
> polygons. Here
> is one filter created by Kosmo
> <ogc:Filter><ogc:Intersects>
> <ogc:PropertyName>lv:the_geom</ogc:PropertyName>
> <gml:Surface>
> <gml:patches>
> <gml:Polygon>
> <gml:exterior>
> <gml:LinearRing>
> <gml:posList>369599.4780422082 6919973.386401318 369599.4780422082
> 6980714.097399444 448217.05381570297 6980714.097399444
> 448217.05381570297 6919973.386401318 369599.4780422082
> 6919973.386401318
> </gml:posList>
> </gml:LinearRing>
> </gml:exterior>
> </gml:Polygon>
> </gml:patches>
> </gml:Surface>
>
> Schema validating TinyOWS says that <gml:Polygon> is illegal and it
> should be <gml:PolygonPatch> instead. I do not know that for sure but
> these links http://jira.codehaus.org/browse/GEOS-2868 and
> http://jira.codehaus.org/secure/attachment/41559/WFS1.1_correc
t_surface_

> request.txt are handling a little bit similar case. The latter lind
> shows a filter that was created by OpenJUMP WFS plugin and it is using
> PolygonPatch.
>
> Geoserver seems to be merciful and in my test with Geoserver
> 2.1 it did
> accept the Kosmo filter with <gml:Polygon>.
>
> B) For some reason the developer WFS read my TinyWFS only with WFS
> version 1.0.0. The two TinyOWS errors I can see in the log are
> [ERROR] Element '{http://www.opengis.net/wfs}Query', attribute
> 'srsName': The attribute 'srsName' is not allowed.
> and
> [ERROR] Element '{http://www.opengis.net/wfs}PropertyName':
> This element
> is not expected. Expected is one of (
> {http://www.opengis.net/ogc}PropertyName,
> {http://www.opengis.net/ogc}Filter ).
>
> I am thinking that TinyOWS is too strict with the additional srsName
> element because even it is not supported by WFS 1.0.0 standart still
> TinyOWS itself supports the use of srsName in GET requests as you can
> test by this
> http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&r
equest=get

> feature&typename=osm_polygon&maxfeatures=20&srsName=EPSG:4326
>
> I can't say anything about the difference of wfs PropertyName and ogc
> PropertyName. I will ask about that from TinyOWS side.
>
> C) Kosmo reads our feature types coming Geoserver 2.1 fine with WFS
> version 1.0.0 so Geoserver is not suffering from the issues
> of the case
> B) above. However, if I make GetFeature requests with WFS 1.1.0 I am
> always getting just one single feature drawn on the Kosmo map. I could
> verify this behaviour by making a totally new Geoserver v. 2.1
> installation and using the Geoserver demo feature types for
> testing. The
> request that is sent by Kosmo is OK with maxFeatures=1000 and I do
> believe that Geoserver WFS is really sending more features
> but Kosmo is
> just parsing the first feature.
>
> D) Spatial filters with WFS 1.0.0 do not work. If you have not done a
> big rewrite for the OpenJUMP WFS plugin version 1.1 I am not surprised
> about it. After the latest modifications into OpenJUMP WFS plugin it
> started to create WFS 1.1.0 style spatial filters even when version
> 1.0.0 is selected. Evidently the developers were not playing with WFS
> 1.0.0 any more and they did not care even they broke the
> 1.0.0 support.
>
> Regards,
>
> -Jukka Rahkonen-
> _______________________________________________
> Kosmo_int mailing list
> [hidden email]
> http://lists.saig.es/mailman/listinfo/kosmo_int
>
_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0 WFS

Sergio Baños Calvo
Hi Jukka.

I've been making some more changes to the WFS connector again. It's available a new developer update at:

http://www.kosmoland.es/public/kosmo/v_2.0/binaries/kd_2.0_update_2011_05_24.zip

The changes made to it includes some bugfixes for things that you pointed in your last mail. I'll do a summary of them (and answer the other questions):

1) Proxy -> GetFeature POST requests

I've added support for proxy configuration that wasn't added to the POST request. If you have configured it properly in Kosmo Desktop configuration tool, in the log file, after each REQUEST should go the proxy parameters used. If no proxy is used, it's also logged.


2) KD - WFS 1.1.0 spatial filters (A)

The filter translator was making a mix of GML2 and GML3 schemas, so it didn't work. I have changed it to take into account requested GML format and it should build the request properly by using it.


3) TinyOWS - WFS requests (B)

- Attribute srsName -> only added for WFS 1.1.0 requests
- ogc:PropertyName -> only for WFS 1.0.0 requests (as defined by WFS 1.0.0 schema)
- wfs:PropertyName -> only for WFS 1.1.0 requests (as defined by WFS 1.1.0 schema)


4) Geoserver WFS (C)

The way that Geoserver 1.1.0 sends the response is a bit different that the one used by TinyOWS (both are supported by the standard): each FeatureCollection feature member can be sent in two ways

a) Geoserver style
<wfs:FeatureCollection>
...
<gml:FeatureMembers>
    <feature1>
    <feature2>
    ....
    <featureN>
</gml:featureMembers>
</gml:FeatureCollection>

b) TinyOWS style
<wfs:FeatureCollection>
...
<gml:FeatureMember>
    <feature1>
</gml:featureMember>
<gml:FeatureMember>
    <feature2>
</gml:featureMember>
....
<gml:FeatureMember>
    <featureN>
</gml:featureMember>
</gml:FeatureCollection>

KD supported b) style, but not a) (it only readed the first feature, and ignore the rest of them). Both styles are now supported.


5) WFS 1.0.0 Spatial filters doesn't work (D)

As you stated in your mail, the WFS 1.1.0 spatial filter style was used, independently from the version selected. I have changed this and the filter is correctly sent to the server (it doesn't complain about it now), but it doesn't give any result in the tests I have done this morning :( (it just returns a response with no features)


6) TinyOWS - WFS 1.1.0

Since last Friday, I haven't be able to load WFS 1.1.0 layers from your testing server: it always sent me an exception response indicating that my GetFeature request is not valid. No luck so far to find what's wrong with it.


7) Filter DWithin operator

It's more a "historic" problem than a current one: when the Filter Builder Wizard was generated, that operation was not supported for our Filter to SQL PostGIS encoder: we decided then to remove it because of that. I think that we can readd it because it should be supported now.

Regards,

El 23/05/2011 14:27, Rahkonen Jukka escribió:
Hi,

I have one simple question: Why Kosmo WFS does not support spatial
filter DWithin? Is it just for avoiding repetition because the same
effect obviously can be achieved by using the Intersects filter with a
buffer?

-Jukka Rahkonen-

Rahkonen Jukka wrote:

  
Hi,

I received your mail just after I had decided to stop the old long
thread and start a new one with a better describing title.

I answer first to your questions, and below will follow the mail I had
prepered for sending earlier.

" I have revised the behaviour of the WFS connector against the 1.0.0
and the GetFeature request was not properly build. I have 
changed it in
order to take into account the exact WFS version that we're using to
connect and now it works as expected." 

Yes, a new version can read features with WFS 1.0.0.  Spatial 
filters do
not work and you can read more about it later in this mail

" Have you give a try to the spatial filters? "
Yes, read more below.

" we can plan a new minor update (for the next week, probably)."
Very much appreciated even if there would be some minory things left.
Finnish language file and improved WFS would be valuable for us.

And here are my comments after testing the yesterdays version.

The developer version of WFS which I received yesterday is definitely
having troubles with proxy. It is sending the final GetFeature as http
POST directly to the destination URL and not to the proxy 
server. I did
not notice that at home because even I use Fiddler software as a
debugging proxy the direct connection is not blocked.
The developer version is having some issues but I cannot investigate
them now pretty well myself because due to the proxy problem I cannot
capture the critical requests and theis headers. It would be 
nice to get
another version with a proxy fix some day. Now I can only report about
how the four issues (A, B, C and D) which I have found this 
far appear.

A) Kosmo is creating faulty WFS 1.1.0 spatial filters for 
polygons. Here
is one filter created by Kosmo
<ogc:Filter><ogc:Intersects>
<ogc:PropertyName>lv:the_geom</ogc:PropertyName>
<gml:Surface>
<gml:patches>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>369599.4780422082 6919973.386401318 369599.4780422082
6980714.097399444 448217.05381570297 6980714.097399444
448217.05381570297 6919973.386401318 369599.4780422082 
6919973.386401318
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:patches>
</gml:Surface>

Schema validating TinyOWS says that <gml:Polygon> is illegal and it
should be <gml:PolygonPatch> instead. I do not know that for sure but
these links http://jira.codehaus.org/browse/GEOS-2868 and
http://jira.codehaus.org/secure/attachment/41559/WFS1.1_correc
t_surface_
request.txt are handling a little bit similar case. The latter lind
shows a filter that was created by OpenJUMP WFS plugin and it is using
PolygonPatch.

Geoserver seems to be merciful and in my test with Geoserver 
2.1 it did
accept the Kosmo filter with <gml:Polygon>.

B) For some reason the developer WFS read my TinyWFS only with WFS
version 1.0.0. The two TinyOWS errors I can see in the log are
[ERROR] Element '{http://www.opengis.net/wfs}Query', attribute
'srsName': The attribute 'srsName' is not allowed.
and
[ERROR] Element '{http://www.opengis.net/wfs}PropertyName': 
This element
is not expected. Expected is one of (
{http://www.opengis.net/ogc}PropertyName,
{http://www.opengis.net/ogc}Filter ).

I am thinking that TinyOWS is too strict with the additional srsName
element because even it is not supported by WFS 1.0.0 standart still
TinyOWS itself supports the use of srsName in GET requests as you can
test by this 
http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&r
equest=get
feature&typename=osm_polygon&maxfeatures=20&srsName=EPSG:4326

I can't say anything about the difference of wfs PropertyName and ogc
PropertyName. I will ask about that from TinyOWS side.

C) Kosmo reads our feature types coming Geoserver 2.1 fine with WFS
version 1.0.0 so Geoserver is not suffering from the issues 
of the case
B) above. However, if I make GetFeature requests with WFS 1.1.0 I am
always getting just one single feature drawn on the Kosmo map. I could
verify this behaviour by making a totally new Geoserver v. 2.1
installation and using the Geoserver demo feature types for 
testing. The
request that is sent by Kosmo is OK with maxFeatures=1000 and I do
believe that Geoserver WFS is really sending more features 
but Kosmo is
just parsing the first feature.

D) Spatial filters with WFS 1.0.0 do not work. If you have not done a
big rewrite for the OpenJUMP WFS plugin version 1.1 I am not surprised
about it. After the latest modifications into OpenJUMP WFS plugin it
started to create WFS 1.1.0 style spatial filters even when version
1.0.0 is selected. Evidently the developers were not playing with WFS
1.0.0 any more and they did not care even they broke the 
1.0.0 support.

Regards,

-Jukka Rahkonen-
_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int

_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int


--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0 WFS

Rahkonen Jukka
Hi,
 
I can see you have been working hard. 
 
1)  POST through the proxy works fine.  I can capture the requests both from Kosmo log file and from Fiddler2 program which I have installed as a localhost proxy.  The latter gathers also all the headers from requests and responses so I have now pretty good possibilities to find the possible problems and make detailed questions for you and TinyOWS developer. This is excellent.
 
2) By a quick look both WFS 1.0.0 and 1.1.0 spatial filters look good to me.
 
3) - On the other hand removing srsName is good from WFS 1.0.0 is good because it is not standard and TinyOWS does not accept it with POST.  On the other hand it would be a pretty usable extension to the standard and TinyOWS does support it with http GET. Geoserver supports using srsName with WFS 1.0.0 too and I believe so does deegree.
- I trust that you know the schemas.
 
4) Kosmo seems to read now perfectly Geoserver 2.1 WFS, congratulations! I have tested the GetFeature for the whole layer, attribute filter with non-ASCII characters and spatial filter Intersects with a polygon .  Everything work both with WFS 1.0.0 and 1.1.0.
 
5) Server says "Data not found".  There should be data and I will check the resultin SQL agains the backend database.
 
6) I will check the logs about the claimed invalid xml. Must be due to recent development on the TinyOWS that has been breaking something else. I do not believe it can be anything really big any more.
 
7) I understand.
 
In conclusion, as a result of the TinyOWS test campaign Kosmo is now a full featured client for Geoserver. If we manage to isolate the issues in 5) and 6) it will be as good partner for TinyOWS as well.
 
-Jukka Rahkonen-
 


Lähettäjä: [hidden email] [mailto:[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 24. toukokuuta 2011 15:58
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0 WFS

Hi Jukka.

I've been making some more changes to the WFS connector again. It's available a new developer update at:

http://www.kosmoland.es/public/kosmo/v_2.0/binaries/kd_2.0_update_2011_05_24.zip

The changes made to it includes some bugfixes for things that you pointed in your last mail. I'll do a summary of them (and answer the other questions):

1) Proxy -> GetFeature POST requests

I've added support for proxy configuration that wasn't added to the POST request. If you have configured it properly in Kosmo Desktop configuration tool, in the log file, after each REQUEST should go the proxy parameters used. If no proxy is used, it's also logged.


2) KD - WFS 1.1.0 spatial filters (A)

The filter translator was making a mix of GML2 and GML3 schemas, so it didn't work. I have changed it to take into account requested GML format and it should build the request properly by using it.


3) TinyOWS - WFS requests (B)

- Attribute srsName -> only added for WFS 1.1.0 requests
- ogc:PropertyName -> only for WFS 1.0.0 requests (as defined by WFS 1.0.0 schema)
- wfs:PropertyName -> only for WFS 1.1.0 requests (as defined by WFS 1.1.0 schema)


4) Geoserver WFS (C)

The way that Geoserver 1.1.0 sends the response is a bit different that the one used by TinyOWS (both are supported by the standard): each FeatureCollection feature member can be sent in two ways

a) Geoserver style
<wfs:FeatureCollection>
...
<gml:FeatureMembers>
    <feature1>
    <feature2>
    ....
    <featureN>
</gml:featureMembers>
</gml:FeatureCollection>

b) TinyOWS style
<wfs:FeatureCollection>
...
<gml:FeatureMember>
    <feature1>
</gml:featureMember>
<gml:FeatureMember>
    <feature2>
</gml:featureMember>
....
<gml:FeatureMember>
    <featureN>
</gml:featureMember>
</gml:FeatureCollection>

KD supported b) style, but not a) (it only readed the first feature, and ignore the rest of them). Both styles are now supported.


5) WFS 1.0.0 Spatial filters doesn't work (D)

As you stated in your mail, the WFS 1.1.0 spatial filter style was used, independently from the version selected. I have changed this and the filter is correctly sent to the server (it doesn't complain about it now), but it doesn't give any result in the tests I have done this morning :( (it just returns a response with no features)


6) TinyOWS - WFS 1.1.0

Since last Friday, I haven't be able to load WFS 1.1.0 layers from your testing server: it always sent me an exception response indicating that my GetFeature request is not valid. No luck so far to find what's wrong with it.


7) Filter DWithin operator

It's more a "historic" problem than a current one: when the Filter Builder Wizard was generated, that operation was not supported for our Filter to SQL PostGIS encoder: we decided then to remove it because of that. I think that we can readd it because it should be supported now.

Regards,

El 23/05/2011 14:27, Rahkonen Jukka escribió:
Hi,

I have one simple question: Why Kosmo WFS does not support spatial
filter DWithin? Is it just for avoiding repetition because the same
effect obviously can be achieved by using the Intersects filter with a
buffer?

-Jukka Rahkonen-

Rahkonen Jukka wrote:

  
Hi,

I received your mail just after I had decided to stop the old long
thread and start a new one with a better describing title.

I answer first to your questions, and below will follow the mail I had
prepered for sending earlier.

" I have revised the behaviour of the WFS connector against the 1.0.0
and the GetFeature request was not properly build. I have 
changed it in
order to take into account the exact WFS version that we're using to
connect and now it works as expected." 

Yes, a new version can read features with WFS 1.0.0.  Spatial 
filters do
not work and you can read more about it later in this mail

" Have you give a try to the spatial filters? "
Yes, read more below.

" we can plan a new minor update (for the next week, probably)."
Very much appreciated even if there would be some minory things left.
Finnish language file and improved WFS would be valuable for us.

And here are my comments after testing the yesterdays version.

The developer version of WFS which I received yesterday is definitely
having troubles with proxy. It is sending the final GetFeature as http
POST directly to the destination URL and not to the proxy 
server. I did
not notice that at home because even I use Fiddler software as a
debugging proxy the direct connection is not blocked.
The developer version is having some issues but I cannot investigate
them now pretty well myself because due to the proxy problem I cannot
capture the critical requests and theis headers. It would be 
nice to get
another version with a proxy fix some day. Now I can only report about
how the four issues (A, B, C and D) which I have found this 
far appear.

A) Kosmo is creating faulty WFS 1.1.0 spatial filters for 
polygons. Here
is one filter created by Kosmo
<ogc:Filter><ogc:Intersects>
<ogc:PropertyName>lv:the_geom</ogc:PropertyName>
<gml:Surface>
<gml:patches>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>369599.4780422082 6919973.386401318 369599.4780422082
6980714.097399444 448217.05381570297 6980714.097399444
448217.05381570297 6919973.386401318 369599.4780422082 
6919973.386401318
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:patches>
</gml:Surface>

Schema validating TinyOWS says that <gml:Polygon> is illegal and it
should be <gml:PolygonPatch> instead. I do not know that for sure but
these links http://jira.codehaus.org/browse/GEOS-2868 and
http://jira.codehaus.org/secure/attachment/41559/WFS1.1_correc
t_surface_
request.txt are handling a little bit similar case. The latter lind
shows a filter that was created by OpenJUMP WFS plugin and it is using
PolygonPatch.

Geoserver seems to be merciful and in my test with Geoserver 
2.1 it did
accept the Kosmo filter with <gml:Polygon>.

B) For some reason the developer WFS read my TinyWFS only with WFS
version 1.0.0. The two TinyOWS errors I can see in the log are
[ERROR] Element '{http://www.opengis.net/wfs}Query', attribute
'srsName': The attribute 'srsName' is not allowed.
and
[ERROR] Element '{http://www.opengis.net/wfs}PropertyName': 
This element
is not expected. Expected is one of (
{http://www.opengis.net/ogc}PropertyName,
{http://www.opengis.net/ogc}Filter ).

I am thinking that TinyOWS is too strict with the additional srsName
element because even it is not supported by WFS 1.0.0 standart still
TinyOWS itself supports the use of srsName in GET requests as you can
test by this 
http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&r
equest=get
feature&typename=osm_polygon&maxfeatures=20&srsName=EPSG:4326

I can't say anything about the difference of wfs PropertyName and ogc
PropertyName. I will ask about that from TinyOWS side.

C) Kosmo reads our feature types coming Geoserver 2.1 fine with WFS
version 1.0.0 so Geoserver is not suffering from the issues 
of the case
B) above. However, if I make GetFeature requests with WFS 1.1.0 I am
always getting just one single feature drawn on the Kosmo map. I could
verify this behaviour by making a totally new Geoserver v. 2.1
installation and using the Geoserver demo feature types for 
testing. The
request that is sent by Kosmo is OK with maxFeatures=1000 and I do
believe that Geoserver WFS is really sending more features 
but Kosmo is
just parsing the first feature.

D) Spatial filters with WFS 1.0.0 do not work. If you have not done a
big rewrite for the OpenJUMP WFS plugin version 1.1 I am not surprised
about it. After the latest modifications into OpenJUMP WFS plugin it
started to create WFS 1.1.0 style spatial filters even when version
1.0.0 is selected. Evidently the developers were not playing with WFS
1.0.0 any more and they did not care even they broke the 
1.0.0 support.

Regards,

-Jukka Rahkonen-
_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int

_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int


--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Testing Kosmo 2.0 WFS

Sergio Baños Calvo
Good morning Jukka.

I have made available a new developer update at:

http://www.kosmoland.es/public/kosmo/v_2.0/binaries/kd_2.0_update_2011_05_27.zip

We have modified the way GML geometries are exported in WFS 1.1.0 requests to conform better the GML schema. In particular:

1) Added srsName attribute to those elements that need it
2) Added srsDimension and count attributes to gml:posList elements

I have tested some WFS 1.1.0 spatial filters against your municipalities layer and they seem to work properly now.

Regards,

El 24/05/2011 16:21, Rahkonen Jukka escribió:
Hi,
 
I can see you have been working hard. 
 
1)  POST through the proxy works fine.  I can capture the requests both from Kosmo log file and from Fiddler2 program which I have installed as a localhost proxy.  The latter gathers also all the headers from requests and responses so I have now pretty good possibilities to find the possible problems and make detailed questions for you and TinyOWS developer. This is excellent.
 
2) By a quick look both WFS 1.0.0 and 1.1.0 spatial filters look good to me.
 
3) - On the other hand removing srsName is good from WFS 1.0.0 is good because it is not standard and TinyOWS does not accept it with POST.  On the other hand it would be a pretty usable extension to the standard and TinyOWS does support it with http GET. Geoserver supports using srsName with WFS 1.0.0 too and I believe so does deegree.
- I trust that you know the schemas.
 
4) Kosmo seems to read now perfectly Geoserver 2.1 WFS, congratulations! I have tested the GetFeature for the whole layer, attribute filter with non-ASCII characters and spatial filter Intersects with a polygon .  Everything work both with WFS 1.0.0 and 1.1.0.
 
5) Server says "Data not found".  There should be data and I will check the resultin SQL agains the backend database.
 
6) I will check the logs about the claimed invalid xml. Must be due to recent development on the TinyOWS that has been breaking something else. I do not believe it can be anything really big any more.
 
7) I understand.
 
In conclusion, as a result of the TinyOWS test campaign Kosmo is now a full featured client for Geoserver. If we manage to isolate the issues in 5) and 6) it will be as good partner for TinyOWS as well.
 
-Jukka Rahkonen-
 


Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 24. toukokuuta 2011 15:58
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Testing Kosmo 2.0 WFS

Hi Jukka.

I've been making some more changes to the WFS connector again. It's available a new developer update at:

http://www.kosmoland.es/public/kosmo/v_2.0/binaries/kd_2.0_update_2011_05_24.zip

The changes made to it includes some bugfixes for things that you pointed in your last mail. I'll do a summary of them (and answer the other questions):

1) Proxy -> GetFeature POST requests

I've added support for proxy configuration that wasn't added to the POST request. If you have configured it properly in Kosmo Desktop configuration tool, in the log file, after each REQUEST should go the proxy parameters used. If no proxy is used, it's also logged.


2) KD - WFS 1.1.0 spatial filters (A)

The filter translator was making a mix of GML2 and GML3 schemas, so it didn't work. I have changed it to take into account requested GML format and it should build the request properly by using it.


3) TinyOWS - WFS requests (B)

- Attribute srsName -> only added for WFS 1.1.0 requests
- ogc:PropertyName -> only for WFS 1.0.0 requests (as defined by WFS 1.0.0 schema)
- wfs:PropertyName -> only for WFS 1.1.0 requests (as defined by WFS 1.1.0 schema)


4) Geoserver WFS (C)

The way that Geoserver 1.1.0 sends the response is a bit different that the one used by TinyOWS (both are supported by the standard): each FeatureCollection feature member can be sent in two ways

a) Geoserver style
<wfs:FeatureCollection>
...
<gml:FeatureMembers>
    <feature1>
    <feature2>
    ....
    <featureN>
</gml:featureMembers>
</gml:FeatureCollection>

b) TinyOWS style
<wfs:FeatureCollection>
...
<gml:FeatureMember>
    <feature1>
</gml:featureMember>
<gml:FeatureMember>
    <feature2>
</gml:featureMember>
....
<gml:FeatureMember>
    <featureN>
</gml:featureMember>
</gml:FeatureCollection>

KD supported b) style, but not a) (it only readed the first feature, and ignore the rest of them). Both styles are now supported.


5) WFS 1.0.0 Spatial filters doesn't work (D)

As you stated in your mail, the WFS 1.1.0 spatial filter style was used, independently from the version selected. I have changed this and the filter is correctly sent to the server (it doesn't complain about it now), but it doesn't give any result in the tests I have done this morning :( (it just returns a response with no features)


6) TinyOWS - WFS 1.1.0

Since last Friday, I haven't be able to load WFS 1.1.0 layers from your testing server: it always sent me an exception response indicating that my GetFeature request is not valid. No luck so far to find what's wrong with it.


7) Filter DWithin operator

It's more a "historic" problem than a current one: when the Filter Builder Wizard was generated, that operation was not supported for our Filter to SQL PostGIS encoder: we decided then to remove it because of that. I think that we can readd it because it should be supported now.

Regards,

El 23/05/2011 14:27, Rahkonen Jukka escribió:
Hi,

I have one simple question: Why Kosmo WFS does not support spatial
filter DWithin? Is it just for avoiding repetition because the same
effect obviously can be achieved by using the Intersects filter with a
buffer?

-Jukka Rahkonen-

Rahkonen Jukka wrote:

  
Hi,

I received your mail just after I had decided to stop the old long
thread and start a new one with a better describing title.

I answer first to your questions, and below will follow the mail I had
prepered for sending earlier.

" I have revised the behaviour of the WFS connector against the 1.0.0
and the GetFeature request was not properly build. I have 
changed it in
order to take into account the exact WFS version that we're using to
connect and now it works as expected." 

Yes, a new version can read features with WFS 1.0.0.  Spatial 
filters do
not work and you can read more about it later in this mail

" Have you give a try to the spatial filters? "
Yes, read more below.

" we can plan a new minor update (for the next week, probably)."
Very much appreciated even if there would be some minory things left.
Finnish language file and improved WFS would be valuable for us.

And here are my comments after testing the yesterdays version.

The developer version of WFS which I received yesterday is definitely
having troubles with proxy. It is sending the final GetFeature as http
POST directly to the destination URL and not to the proxy 
server. I did
not notice that at home because even I use Fiddler software as a
debugging proxy the direct connection is not blocked.
The developer version is having some issues but I cannot investigate
them now pretty well myself because due to the proxy problem I cannot
capture the critical requests and theis headers. It would be 
nice to get
another version with a proxy fix some day. Now I can only report about
how the four issues (A, B, C and D) which I have found this 
far appear.

A) Kosmo is creating faulty WFS 1.1.0 spatial filters for 
polygons. Here
is one filter created by Kosmo
<ogc:Filter><ogc:Intersects>
<ogc:PropertyName>lv:the_geom</ogc:PropertyName>
<gml:Surface>
<gml:patches>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>369599.4780422082 6919973.386401318 369599.4780422082
6980714.097399444 448217.05381570297 6980714.097399444
448217.05381570297 6919973.386401318 369599.4780422082 
6919973.386401318
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:patches>
</gml:Surface>

Schema validating TinyOWS says that <gml:Polygon> is illegal and it
should be <gml:PolygonPatch> instead. I do not know that for sure but
these links http://jira.codehaus.org/browse/GEOS-2868 and
http://jira.codehaus.org/secure/attachment/41559/WFS1.1_correc
t_surface_
request.txt are handling a little bit similar case. The latter lind
shows a filter that was created by OpenJUMP WFS plugin and it is using
PolygonPatch.

Geoserver seems to be merciful and in my test with Geoserver 
2.1 it did
accept the Kosmo filter with <gml:Polygon>.

B) For some reason the developer WFS read my TinyWFS only with WFS
version 1.0.0. The two TinyOWS errors I can see in the log are
[ERROR] Element '{http://www.opengis.net/wfs}Query', attribute
'srsName': The attribute 'srsName' is not allowed.
and
[ERROR] Element '{http://www.opengis.net/wfs}PropertyName': 
This element
is not expected. Expected is one of (
{http://www.opengis.net/ogc}PropertyName,
{http://www.opengis.net/ogc}Filter ).

I am thinking that TinyOWS is too strict with the additional srsName
element because even it is not supported by WFS 1.0.0 standart still
TinyOWS itself supports the use of srsName in GET requests as you can
test by this 
http://188.64.1.61/cgi-bin/tinyows?service=wfs&version=1.0.0&r
equest=get
feature&typename=osm_polygon&maxfeatures=20&srsName=EPSG:4326

I can't say anything about the difference of wfs PropertyName and ogc
PropertyName. I will ask about that from TinyOWS side.

C) Kosmo reads our feature types coming Geoserver 2.1 fine with WFS
version 1.0.0 so Geoserver is not suffering from the issues 
of the case
B) above. However, if I make GetFeature requests with WFS 1.1.0 I am
always getting just one single feature drawn on the Kosmo map. I could
verify this behaviour by making a totally new Geoserver v. 2.1
installation and using the Geoserver demo feature types for 
testing. The
request that is sent by Kosmo is OK with maxFeatures=1000 and I do
believe that Geoserver WFS is really sending more features 
but Kosmo is
just parsing the first feature.

D) Spatial filters with WFS 1.0.0 do not work. If you have not done a
big rewrite for the OpenJUMP WFS plugin version 1.1 I am not surprised
about it. After the latest modifications into OpenJUMP WFS plugin it
started to create WFS 1.1.0 style spatial filters even when version
1.0.0 is selected. Evidently the developers were not playing with WFS
1.0.0 any more and they did not care even they broke the 
1.0.0 support.

Regards,

-Jukka Rahkonen-
_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int

_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int


--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Kosmo does not start with limited user rights

Rahkonen Jukka
In reply to this post by Rahkonen Jukka
Hi,

I have a problem when trying to start Kosmo on Windows XP when logged in with our normal user role. Progress stops when the project libraries should be loaded and my log file shows the following information about denied use of jgdal061.dll

01/06/2011 14:34:12  INFO JUMPWorkbench:386 - Käynnistää sovellusta Kosmo-GIS 2.0.1 (20110524) - 1.6.2011 14:34:12
01/06/2011 14:34:12  INFO JUMPWorkbench:392 - Java-versio : 1.6.0_23
01/06/2011 14:34:12  INFO JUMPWorkbench:394 - Käyttöjärjestelmä : Windows XP (5.1)
01/06/2011 14:34:12  INFO JUMPWorkbench:614 - Käytetään ulkoasua com.sun.java.swing.plaf.windows.WindowsLookAndFeel
01/06/2011 14:34:12  INFO JUMPWorkbench:463 - Asetetaan lokitiedoston keräystaso arvoon INFO
01/06/2011 14:34:17  INFO JUMPWorkbench:282 - Ladataan projektiokirjastoja...
01/06/2011 14:34:24 ERROR root:197 - Exception in thread "main"
01/06/2011 14:34:24 ERROR root:197 - java.lang.UnsatisfiedLinkError: D:\ohjelmat\Kosmo_20\dlls\jgdal061.dll: Käyttö estetty
01/06/2011 14:34:24 ERROR root:197 - at java.lang.ClassLoader$NativeLibrary.load(Native Method)
01/06/2011 14:34:24 ERROR root:197 - at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
01/06/2011 14:34:24 ERROR root:197 - at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728)
01/06/2011 14:34:24 ERROR root:197 - at java.lang.Runtime.loadLibrary0(Runtime.java:823)
01/06/2011 14:34:24 ERROR root:197 - at java.lang.System.loadLibrary(System.java:1028)
01/06/2011 14:34:24 ERROR root:197 - at org.gvsig.crs.ogr.JNIBase.<clinit>(JNIBase.java:79)
01/06/2011 14:34:24 ERROR root:197 - at org.gvsig.crs.Crs.<init>(Crs.java:208)
01/06/2011 14:34:24 ERROR root:197 - at org.gvsig.crs.repository.EpsgRepository.getCrs(EpsgRepository.java:144)
01/06/2011 14:34:24 ERROR root:197 - at org.gvsig.crs.CrsFactory.getCRS(CrsFactory.java:92)
01/06/2011 14:34:24 ERROR root:197 - at org.saig.core.util.CrsManager.getCRS(CrsManager.java:90)
01/06/2011 14:34:24 ERROR root:197 - at com.vividsolutions.jump.workbench.JUMPWorkbench.<init>(JUMPWorkbench.java:285)
01/06/2011 14:34:24 ERROR root:197 - at com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:434)

Kosmo starts normally if I log in as admin.

-Jukka Rahkonen-
_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Kosmo does not start with limited user rights

Sergio Baños Calvo
Hi Jukka.

Could you give me more hints about your issue? I need to know which user installed / unzipped Kosmo Desktop and if the normal user role can change the value for the PATH variable (Kosmo.bat updates the PATH enviroment variable to include the /dlls directory to it for its command session):

SET PATH=..\dlls;%PATH%
start.\jre\bin\javaw -Djava.library.path="..\dlls" -Dsun.java2d.d3d=false -cp .;./saig.jar -Xmx800M com.vividsolutions.jump.workbench.JUMPWorkbench -plug-in-directory ./ext


Another problem could be the Kosmo Desktop install path used, but your path (D:\ohjelmat\Kosmo_20) seems ok to me, as it doesn't contain spetial characters or spaces.

Anyway, you could try some approaches to solve it:

Option 1) Add the dlls directory to your system global path variable (D:\ohjelmat\Kosmo_20\dlls)

Option 2) Modify the Kosmo.bat file to use absolute paths instead of relative paths:

SET PATH=D:\ohjelmat\Kosmo_20\dlls;%PATH%
start.\jre\bin\javaw -Djava.library.path="D:\ohjelmat\Kosmo_20\dlls" -Dsun.java2d.d3d=false -cp .;./saig.jar -Xmx800M com.vividsolutions.jump.workbench.JUMPWorkbench -plug-in-directory ./ext


Option 3) Copy all the files present at /dlls to /bin/jre/bin


Regards,

El 01/06/2011 13:43, Rahkonen Jukka escribió:
Hi,

I have a problem when trying to start Kosmo on Windows XP when logged in with our normal user role. Progress stops when the project libraries should be loaded and my log file shows the following information about denied use of jgdal061.dll 

01/06/2011 14:34:12  INFO JUMPWorkbench:386 - Käynnistää sovellusta Kosmo-GIS 2.0.1 (20110524) - 1.6.2011 14:34:12
01/06/2011 14:34:12  INFO JUMPWorkbench:392 - Java-versio : 1.6.0_23
01/06/2011 14:34:12  INFO JUMPWorkbench:394 - Käyttöjärjestelmä : Windows XP (5.1)
01/06/2011 14:34:12  INFO JUMPWorkbench:614 - Käytetään ulkoasua com.sun.java.swing.plaf.windows.WindowsLookAndFeel
01/06/2011 14:34:12  INFO JUMPWorkbench:463 - Asetetaan lokitiedoston keräystaso arvoon INFO
01/06/2011 14:34:17  INFO JUMPWorkbench:282 - Ladataan projektiokirjastoja...
01/06/2011 14:34:24 ERROR root:197 - Exception in thread "main" 
01/06/2011 14:34:24 ERROR root:197 - java.lang.UnsatisfiedLinkError: D:\ohjelmat\Kosmo_20\dlls\jgdal061.dll: Käyttö estetty
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.Runtime.loadLibrary0(Runtime.java:823)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.System.loadLibrary(System.java:1028)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.ogr.JNIBase.<clinit>(JNIBase.java:79)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.Crs.<init>(Crs.java:208)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.repository.EpsgRepository.getCrs(EpsgRepository.java:144)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.CrsFactory.getCRS(CrsFactory.java:92)
01/06/2011 14:34:24 ERROR root:197 - 	at org.saig.core.util.CrsManager.getCRS(CrsManager.java:90)
01/06/2011 14:34:24 ERROR root:197 - 	at com.vividsolutions.jump.workbench.JUMPWorkbench.<init>(JUMPWorkbench.java:285)
01/06/2011 14:34:24 ERROR root:197 - 	at com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:434)

Kosmo starts normally if I log in as admin.

-Jukka Rahkonen-
_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int


--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Kosmo does not start with limited user rights

Rahkonen Jukka
Hi,
 
Copying all .dll files into \jre\bin made Kosmo to start.  Use do have rights for changing the PATH variable as can be seen from the output after running the bat
D:\ohjelmat\Kosmo_20\bin>path
PATH=..\dlls;C:\...
 
Giving absolute path into dlls worked also.
Installation was done from Windows installer icluding Java as an admin role. 
 
Thanks for the answer, now I at least know how I can make Kosmo to start even it is a bit odd why it starts for the admin but not for a normal user if the only thing that the kosmo.bat actually is doing is to set the dll path.
OpenJUMP batch files, by the way, do work for normal users.
 
-Jukka Rahkonen-
 
 
 

Lähettäjä: [hidden email] [mailto:[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 7. kesäkuuta 2011 15:58
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Kosmo does not start with limited user rights

Hi Jukka.

Could you give me more hints about your issue? I need to know which user installed / unzipped Kosmo Desktop and if the normal user role can change the value for the PATH variable (Kosmo.bat updates the PATH enviroment variable to include the /dlls directory to it for its command session):

SET PATH=..\dlls;%PATH%
start.\jre\bin\javaw -Djava.library.path="..\dlls" -Dsun.java2d.d3d=false -cp .;./saig.jar -Xmx800M com.vividsolutions.jump.workbench.JUMPWorkbench -plug-in-directory ./ext


Another problem could be the Kosmo Desktop install path used, but your path (D:\ohjelmat\Kosmo_20) seems ok to me, as it doesn't contain spetial characters or spaces.

Anyway, you could try some approaches to solve it:

Option 1) Add the dlls directory to your system global path variable (D:\ohjelmat\Kosmo_20\dlls)

Option 2) Modify the Kosmo.bat file to use absolute paths instead of relative paths:

SET PATH=D:\ohjelmat\Kosmo_20\dlls;%PATH%
start.\jre\bin\javaw -Djava.library.path="D:\ohjelmat\Kosmo_20\dlls" -Dsun.java2d.d3d=false -cp .;./saig.jar -Xmx800M com.vividsolutions.jump.workbench.JUMPWorkbench -plug-in-directory ./ext


Option 3) Copy all the files present at /dlls to /bin/jre/bin


Regards,

El 01/06/2011 13:43, Rahkonen Jukka escribió:
Hi,

I have a problem when trying to start Kosmo on Windows XP when logged in with our normal user role. Progress stops when the project libraries should be loaded and my log file shows the following information about denied use of jgdal061.dll 

01/06/2011 14:34:12  INFO JUMPWorkbench:386 - Käynnistää sovellusta Kosmo-GIS 2.0.1 (20110524) - 1.6.2011 14:34:12
01/06/2011 14:34:12  INFO JUMPWorkbench:392 - Java-versio : 1.6.0_23
01/06/2011 14:34:12  INFO JUMPWorkbench:394 - Käyttöjärjestelmä : Windows XP (5.1)
01/06/2011 14:34:12  INFO JUMPWorkbench:614 - Käytetään ulkoasua com.sun.java.swing.plaf.windows.WindowsLookAndFeel
01/06/2011 14:34:12  INFO JUMPWorkbench:463 - Asetetaan lokitiedoston keräystaso arvoon INFO
01/06/2011 14:34:17  INFO JUMPWorkbench:282 - Ladataan projektiokirjastoja...
01/06/2011 14:34:24 ERROR root:197 - Exception in thread "main" 
01/06/2011 14:34:24 ERROR root:197 - java.lang.UnsatisfiedLinkError: D:\ohjelmat\Kosmo_20\dlls\jgdal061.dll: Käyttö estetty
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.Runtime.loadLibrary0(Runtime.java:823)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.System.loadLibrary(System.java:1028)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.ogr.JNIBase.<clinit>(JNIBase.java:79)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.Crs.<init>(Crs.java:208)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.repository.EpsgRepository.getCrs(EpsgRepository.java:144)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.CrsFactory.getCRS(CrsFactory.java:92)
01/06/2011 14:34:24 ERROR root:197 - 	at org.saig.core.util.CrsManager.getCRS(CrsManager.java:90)
01/06/2011 14:34:24 ERROR root:197 - 	at com.vividsolutions.jump.workbench.JUMPWorkbench.<init>(JUMPWorkbench.java:285)
01/06/2011 14:34:24 ERROR root:197 - 	at com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:434)

Kosmo starts normally if I log in as admin.

-Jukka Rahkonen-
_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int


--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Kosmo does not start with limited user rights

Sergio Baños Calvo
Hi Jukka.

I'll take a look into OpenJUMP batch files to see what's the difference with our bat. Thank you for the hint :)

Regards,

El 07/06/2011 15:23, Rahkonen Jukka escribió:
Hi,
 
Copying all .dll files into \jre\bin made Kosmo to start.  Use do have rights for changing the PATH variable as can be seen from the output after running the bat
D:\ohjelmat\Kosmo_20\bin>path
PATH=..\dlls;C:\...
 
Giving absolute path into dlls worked also.
Installation was done from Windows installer icluding Java as an admin role. 
 
Thanks for the answer, now I at least know how I can make Kosmo to start even it is a bit odd why it starts for the admin but not for a normal user if the only thing that the kosmo.bat actually is doing is to set the dll path.
OpenJUMP batch files, by the way, do work for normal users.
 
-Jukka Rahkonen-
 
 
 

Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 7. kesäkuuta 2011 15:58
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Kosmo does not start with limited user rights

Hi Jukka.

Could you give me more hints about your issue? I need to know which user installed / unzipped Kosmo Desktop and if the normal user role can change the value for the PATH variable (Kosmo.bat updates the PATH enviroment variable to include the /dlls directory to it for its command session):

SET PATH=..\dlls;%PATH%
start.\jre\bin\javaw -Djava.library.path="..\dlls" -Dsun.java2d.d3d=false -cp .;./saig.jar -Xmx800M com.vividsolutions.jump.workbench.JUMPWorkbench -plug-in-directory ./ext


Another problem could be the Kosmo Desktop install path used, but your path (D:\ohjelmat\Kosmo_20) seems ok to me, as it doesn't contain spetial characters or spaces.

Anyway, you could try some approaches to solve it:

Option 1) Add the dlls directory to your system global path variable (D:\ohjelmat\Kosmo_20\dlls)

Option 2) Modify the Kosmo.bat file to use absolute paths instead of relative paths:

SET PATH=D:\ohjelmat\Kosmo_20\dlls;%PATH%
start.\jre\bin\javaw -Djava.library.path="D:\ohjelmat\Kosmo_20\dlls" -Dsun.java2d.d3d=false -cp .;./saig.jar -Xmx800M com.vividsolutions.jump.workbench.JUMPWorkbench -plug-in-directory ./ext


Option 3) Copy all the files present at /dlls to /bin/jre/bin


Regards,

El 01/06/2011 13:43, Rahkonen Jukka escribió:
Hi,

I have a problem when trying to start Kosmo on Windows XP when logged in with our normal user role. Progress stops when the project libraries should be loaded and my log file shows the following information about denied use of jgdal061.dll 

01/06/2011 14:34:12  INFO JUMPWorkbench:386 - Käynnistää sovellusta Kosmo-GIS 2.0.1 (20110524) - 1.6.2011 14:34:12
01/06/2011 14:34:12  INFO JUMPWorkbench:392 - Java-versio : 1.6.0_23
01/06/2011 14:34:12  INFO JUMPWorkbench:394 - Käyttöjärjestelmä : Windows XP (5.1)
01/06/2011 14:34:12  INFO JUMPWorkbench:614 - Käytetään ulkoasua com.sun.java.swing.plaf.windows.WindowsLookAndFeel
01/06/2011 14:34:12  INFO JUMPWorkbench:463 - Asetetaan lokitiedoston keräystaso arvoon INFO
01/06/2011 14:34:17  INFO JUMPWorkbench:282 - Ladataan projektiokirjastoja...
01/06/2011 14:34:24 ERROR root:197 - Exception in thread "main" 
01/06/2011 14:34:24 ERROR root:197 - java.lang.UnsatisfiedLinkError: D:\ohjelmat\Kosmo_20\dlls\jgdal061.dll: Käyttö estetty
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.Runtime.loadLibrary0(Runtime.java:823)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.System.loadLibrary(System.java:1028)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.ogr.JNIBase.<clinit>(JNIBase.java:79)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.Crs.<init>(Crs.java:208)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.repository.EpsgRepository.getCrs(EpsgRepository.java:144)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.CrsFactory.getCRS(CrsFactory.java:92)
01/06/2011 14:34:24 ERROR root:197 - 	at org.saig.core.util.CrsManager.getCRS(CrsManager.java:90)
01/06/2011 14:34:24 ERROR root:197 - 	at com.vividsolutions.jump.workbench.JUMPWorkbench.<init>(JUMPWorkbench.java:285)
01/06/2011 14:34:24 ERROR root:197 - 	at com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:434)

Kosmo starts normally if I log in as admin.

-Jukka Rahkonen-
_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int


--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Kosmo does not start with limited user rights

Rahkonen Jukka
Hi,
 
I can not reproduce the error with another computer, with limited rights and this time with zip file installation.  I did zip file installation because of  limited rights, I have no admin account for this computer. There must be something special on that certain computer, perhaps some version mismatch with similarly named dlls locating in many places along the path or something. I believe there isn't much to be worried about.
 
-Jukka Rahkonen-


Lähettäjä: [hidden email] [mailto:[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 7. kesäkuuta 2011 16:30
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Kosmo does not start with limited user rights

Hi Jukka.

I'll take a look into OpenJUMP batch files to see what's the difference with our bat. Thank you for the hint :)

Regards,

El 07/06/2011 15:23, Rahkonen Jukka escribió:
Hi,
 
Copying all .dll files into \jre\bin made Kosmo to start.  Use do have rights for changing the PATH variable as can be seen from the output after running the bat
D:\ohjelmat\Kosmo_20\bin>path
PATH=..\dlls;C:\...
 
Giving absolute path into dlls worked also.
Installation was done from Windows installer icluding Java as an admin role. 
 
Thanks for the answer, now I at least know how I can make Kosmo to start even it is a bit odd why it starts for the admin but not for a normal user if the only thing that the kosmo.bat actually is doing is to set the dll path.
OpenJUMP batch files, by the way, do work for normal users.
 
-Jukka Rahkonen-
 
 
 

Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 7. kesäkuuta 2011 15:58
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Kosmo does not start with limited user rights

Hi Jukka.

Could you give me more hints about your issue? I need to know which user installed / unzipped Kosmo Desktop and if the normal user role can change the value for the PATH variable (Kosmo.bat updates the PATH enviroment variable to include the /dlls directory to it for its command session):

SET PATH=..\dlls;%PATH%
start.\jre\bin\javaw -Djava.library.path="..\dlls" -Dsun.java2d.d3d=false -cp .;./saig.jar -Xmx800M com.vividsolutions.jump.workbench.JUMPWorkbench -plug-in-directory ./ext


Another problem could be the Kosmo Desktop install path used, but your path (D:\ohjelmat\Kosmo_20) seems ok to me, as it doesn't contain spetial characters or spaces.

Anyway, you could try some approaches to solve it:

Option 1) Add the dlls directory to your system global path variable (D:\ohjelmat\Kosmo_20\dlls)

Option 2) Modify the Kosmo.bat file to use absolute paths instead of relative paths:

SET PATH=D:\ohjelmat\Kosmo_20\dlls;%PATH%
start.\jre\bin\javaw -Djava.library.path="D:\ohjelmat\Kosmo_20\dlls" -Dsun.java2d.d3d=false -cp .;./saig.jar -Xmx800M com.vividsolutions.jump.workbench.JUMPWorkbench -plug-in-directory ./ext


Option 3) Copy all the files present at /dlls to /bin/jre/bin


Regards,

El 01/06/2011 13:43, Rahkonen Jukka escribió:
Hi,

I have a problem when trying to start Kosmo on Windows XP when logged in with our normal user role. Progress stops when the project libraries should be loaded and my log file shows the following information about denied use of jgdal061.dll 

01/06/2011 14:34:12  INFO JUMPWorkbench:386 - Käynnistää sovellusta Kosmo-GIS 2.0.1 (20110524) - 1.6.2011 14:34:12
01/06/2011 14:34:12  INFO JUMPWorkbench:392 - Java-versio : 1.6.0_23
01/06/2011 14:34:12  INFO JUMPWorkbench:394 - Käyttöjärjestelmä : Windows XP (5.1)
01/06/2011 14:34:12  INFO JUMPWorkbench:614 - Käytetään ulkoasua com.sun.java.swing.plaf.windows.WindowsLookAndFeel
01/06/2011 14:34:12  INFO JUMPWorkbench:463 - Asetetaan lokitiedoston keräystaso arvoon INFO
01/06/2011 14:34:17  INFO JUMPWorkbench:282 - Ladataan projektiokirjastoja...
01/06/2011 14:34:24 ERROR root:197 - Exception in thread "main" 
01/06/2011 14:34:24 ERROR root:197 - java.lang.UnsatisfiedLinkError: D:\ohjelmat\Kosmo_20\dlls\jgdal061.dll: Käyttö estetty
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.Runtime.loadLibrary0(Runtime.java:823)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.System.loadLibrary(System.java:1028)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.ogr.JNIBase.<clinit>(JNIBase.java:79)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.Crs.<init>(Crs.java:208)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.repository.EpsgRepository.getCrs(EpsgRepository.java:144)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.CrsFactory.getCRS(CrsFactory.java:92)
01/06/2011 14:34:24 ERROR root:197 - 	at org.saig.core.util.CrsManager.getCRS(CrsManager.java:90)
01/06/2011 14:34:24 ERROR root:197 - 	at com.vividsolutions.jump.workbench.JUMPWorkbench.<init>(JUMPWorkbench.java:285)
01/06/2011 14:34:24 ERROR root:197 - 	at com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:434)

Kosmo starts normally if I log in as admin.

-Jukka Rahkonen-
_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int


--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
Reply | Threaded
Open this post in threaded view
|

Re: Kosmo does not start with limited user rights

Rahkonen Jukka
In reply to this post by Sergio Baños Calvo
Hi,
 
I can repeat this behaviour with the problematic computer and I have localized the dll causing troubles. I am getting the same error both by using Kosmo 2.0.1 Windows installer and the zip file installation. What I do not understand is why the problem occurs only with normal user account but not with admin account.
 
For starting Kosmo with my normal user account I must move or copy one single dll into another directory.  The dll is "msvcp71.dll" and if I move it from \Kosmo-2.0.1\dlls into \Kosmo-2.0.1\bin\jre\bin the program starts.  There is no need to touch on any other dlls.  There is no need to move the dll if I log in as admin.  I checked that the path variable, after running the kosmo.bat launcher, is identical for both accounts.  I also checked that also the normal user have full rights for the both directories and also for the dlls.  Really odd situation and I do not believe that the same will happen to many other users.
 
-Jukka Rahkonen-
 
 


Lähettäjä: [hidden email] [mailto:[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 7. kesäkuuta 2011 16:30
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Kosmo does not start with limited user rights

Hi Jukka.

I'll take a look into OpenJUMP batch files to see what's the difference with our bat. Thank you for the hint :)

Regards,

El 07/06/2011 15:23, Rahkonen Jukka escribió:
Hi,
 
Copying all .dll files into \jre\bin made Kosmo to start.  Use do have rights for changing the PATH variable as can be seen from the output after running the bat
D:\ohjelmat\Kosmo_20\bin>path
PATH=..\dlls;C:\...
 
Giving absolute path into dlls worked also.
Installation was done from Windows installer icluding Java as an admin role. 
 
Thanks for the answer, now I at least know how I can make Kosmo to start even it is a bit odd why it starts for the admin but not for a normal user if the only thing that the kosmo.bat actually is doing is to set the dll path.
OpenJUMP batch files, by the way, do work for normal users.
 
-Jukka Rahkonen-
 
 
 

Lähettäjä: [hidden email] [[hidden email]] Puolesta Sergio Baños Calvo
Lähetetty: 7. kesäkuuta 2011 15:58
Vastaanottaja: International Kosmo mailing list (english languaje)
Aihe: Re: [Kosmo_int] Kosmo does not start with limited user rights

Hi Jukka.

Could you give me more hints about your issue? I need to know which user installed / unzipped Kosmo Desktop and if the normal user role can change the value for the PATH variable (Kosmo.bat updates the PATH enviroment variable to include the /dlls directory to it for its command session):

SET PATH=..\dlls;%PATH%
start.\jre\bin\javaw -Djava.library.path="..\dlls" -Dsun.java2d.d3d=false -cp .;./saig.jar -Xmx800M com.vividsolutions.jump.workbench.JUMPWorkbench -plug-in-directory ./ext


Another problem could be the Kosmo Desktop install path used, but your path (D:\ohjelmat\Kosmo_20) seems ok to me, as it doesn't contain spetial characters or spaces.

Anyway, you could try some approaches to solve it:

Option 1) Add the dlls directory to your system global path variable (D:\ohjelmat\Kosmo_20\dlls)

Option 2) Modify the Kosmo.bat file to use absolute paths instead of relative paths:

SET PATH=D:\ohjelmat\Kosmo_20\dlls;%PATH%
start.\jre\bin\javaw -Djava.library.path="D:\ohjelmat\Kosmo_20\dlls" -Dsun.java2d.d3d=false -cp .;./saig.jar -Xmx800M com.vividsolutions.jump.workbench.JUMPWorkbench -plug-in-directory ./ext


Option 3) Copy all the files present at /dlls to /bin/jre/bin


Regards,

El 01/06/2011 13:43, Rahkonen Jukka escribió:
Hi,

I have a problem when trying to start Kosmo on Windows XP when logged in with our normal user role. Progress stops when the project libraries should be loaded and my log file shows the following information about denied use of jgdal061.dll 

01/06/2011 14:34:12  INFO JUMPWorkbench:386 - Käynnistää sovellusta Kosmo-GIS 2.0.1 (20110524) - 1.6.2011 14:34:12
01/06/2011 14:34:12  INFO JUMPWorkbench:392 - Java-versio : 1.6.0_23
01/06/2011 14:34:12  INFO JUMPWorkbench:394 - Käyttöjärjestelmä : Windows XP (5.1)
01/06/2011 14:34:12  INFO JUMPWorkbench:614 - Käytetään ulkoasua com.sun.java.swing.plaf.windows.WindowsLookAndFeel
01/06/2011 14:34:12  INFO JUMPWorkbench:463 - Asetetaan lokitiedoston keräystaso arvoon INFO
01/06/2011 14:34:17  INFO JUMPWorkbench:282 - Ladataan projektiokirjastoja...
01/06/2011 14:34:24 ERROR root:197 - Exception in thread "main" 
01/06/2011 14:34:24 ERROR root:197 - java.lang.UnsatisfiedLinkError: D:\ohjelmat\Kosmo_20\dlls\jgdal061.dll: Käyttö estetty
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.Runtime.loadLibrary0(Runtime.java:823)
01/06/2011 14:34:24 ERROR root:197 - 	at java.lang.System.loadLibrary(System.java:1028)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.ogr.JNIBase.<clinit>(JNIBase.java:79)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.Crs.<init>(Crs.java:208)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.repository.EpsgRepository.getCrs(EpsgRepository.java:144)
01/06/2011 14:34:24 ERROR root:197 - 	at org.gvsig.crs.CrsFactory.getCRS(CrsFactory.java:92)
01/06/2011 14:34:24 ERROR root:197 - 	at org.saig.core.util.CrsManager.getCRS(CrsManager.java:90)
01/06/2011 14:34:24 ERROR root:197 - 	at com.vividsolutions.jump.workbench.JUMPWorkbench.<init>(JUMPWorkbench.java:285)
01/06/2011 14:34:24 ERROR root:197 - 	at com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.java:434)

Kosmo starts normally if I log in as admin.

-Jukka Rahkonen-
_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int


--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]

_______________________________________________ Kosmo_int mailing list [hidden email] http://lists.saig.es/mailman/listinfo/kosmo_int

--

Sergio Baños Calvo

Jefe de desarrollos
Sistemas Abiertos de Información Geográfica, S.L. (SAIG S.L.)
Tlfno. móvil: 685005960
Tlfno. fijo: (+34) 954788876

E-mail: [hidden email]


_______________________________________________
Kosmo_int mailing list
[hidden email]
http://lists.saig.es/mailman/listinfo/kosmo_int
123