Hi Sami,
Thank you for your help. As you can see on the attached file, the ortophoto
is now shown correctly. You can check it on our server on the following
link:
http://151.80.143.120/GIS_4.3.3_MfE/GIS_Client_DEM_20150811/index.xhtml
I will try to share cross-origin source and also try to solve the problem
of the edges (that you can see still on attached) on my own. I will tell
you how everything is going.
Best regards,
Ibon
2015-08-11 6:39 GMT+00:00 Sami J <sami.jylkka at cyberlightning.com>:
> Hi Ibon,
> I hope you are doing well.
>
> I made some new changes to the client code and uploaded them to the
> github. I modified client logic so that CRS:84 definition is used always
> when requesting data from server. So this is used for both texture and
> terrain data. Client is not yet final one, but should be mature enough for
> you to test. Change was done only to GIS_Client_DEM, so other clients
> didn't adopt this logic. If there is still problems with the texture I'm
> happy to check it.
>
> >>Also about you asked on this topic, how can I share cross-origin
> resource of my ortophoto to you to be able to test it in future situations?
> yes, this is very handy feature and there's short guide in the wiki.
> Here's the link:
> http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/GIS_Data_Provider_-_Installation_and_Administration_Guide#Configuration_for_allowing_cross-origin_requests
>
> I'll try to explain insight why edges occurs between terrain blocks:
> When elevation data is uploaded to the server, there are exact elevation
> points in the source data. And when client requests elevation data in the
> area which corners are exactly those kind of points where elevation were
> also originally specified, server is able to return elevation data so that
> each block edge elevation values nicely match with the next block edge
> values. However edge problem occurs when client requests elevation data
> from the area which corners aren't exactly original elevation definition
> points. For this reason server needs to dynamically calculate terrain block
> edge elevation information. And because these edge elevation values are
> estimations calculated by the server, there is change that elevation values
> in the block edges aren't same with the next block. To overcome this
> problem client needs to be able to create terrain block objects so that
> block edge elevation values in the octet-stream returned by the server are
> modified to match with the next terrain block.
>
> I hope this helps you!
>
> Best regards,
> Sami
>
> On Fri, Aug 7, 2015 at 11:08 AM, Ibon Salbidegoitia <ibon.salbi at gmail.com>
> wrote:
>
>> Hi Sami,
>>
>> Thank you for the link.
>> I updated the GIS_Client_DEM and now the LIDAR tif is available to be
>> displayed (check in attached Img1.png or directly on
>> http://151.80.143.120/GIS_4.3.3_MfE/GIS_Client_DEM_20150807/index.xhtml).
>>
>> As you can see the ortophoto does not appear. This could be due to the
>> different SRS projections as Juha told in a previous email? Also about you
>> asked on this topic, how can I share cross-origin resource of my ortophoto
>> to you to be able to test it in future situations?
>>
>> I also would like to ask you about some errors on loading the tiles. As
>> you can see on attached Img2.png, it seems that there is something wrong on
>> the edges. I checked different edges and maybe the most clear photo is
>> attached Img3.png image where it seems that there is a problem with the
>> offset of location (maybe). What do you think about it?
>>
>> Best regards,
>> Ibon
>>
>> 2015-08-06 8:15 GMT+02:00 Sami J <sami.jylkka at cyberlightning.com>:
>>
>>> Hi Ibon,
>>> I didn't yet made any release but only updated client source code to the
>>> github. I was in assumption that we've already shared github link to the
>>> refrerence client source code to you, but clearly that is not the case. I'm
>>> very sorry about that, here's the github link:
>>> https://github.com/Cyberlightning/Cyber-WeX/tree/master/GIS
>>>
>>> So I just made few changes to the reference client, there's no need to
>>> for you to do any changes to geoserver.war. After you have updated
>>> reference client (GIS_Client_DEM) to your VM, you should be able to use
>>> your LIDAR tif as a source for elevation data.
>>>
>>> Best regards,
>>> Sami
>>>
>>>
>>> On Wed, Aug 5, 2015 at 8:41 PM, Ibon Salbidegoitia <ibon.salbi at gmail.com
>>> > wrote:
>>>
>>>> Hi Sami,
>>>>
>>>> When you say that you uploaded changes to the github, you mean that I
>>>> have to compile again geoserver WAR with the source? I suppose it is
>>>> because I haven't seen updates on
>>>> https://forge.fiware.org/frs/?group_id=7 for
>>>> section MIWI-GISDataProvider, so I suppose that the war is still not
>>>> available.
>>>> Or maybe I am wrong, and you refer that you change the test assest JS
>>>> code. But in this case I don't know to which Github you refer as I didn't
>>>> know about this source on Github.
>>>> Please, can you clarify it to be able to test your changes?
>>>> Thank you in advance. Best regards,
>>>>
>>>> Ibon
>>>>
>>>>
>>>> 2015-08-04 13:20 GMT+00:00 Sami J <sami.jylkka at cyberlightning.com>:
>>>>
>>>>> Hi Ibon,
>>>>> I made quick changes to the GIS_Client_DEM source and it seems to work
>>>>> better now with LIDAR dataset. Client didn't previously handle
>>>>> NoDataValaues correctly, so I added logic where all noDataValues are
>>>>> replaced with "0". Now elevation model is properly created based on the
>>>>> octet-stream data. I also replaced hardcoded SRS value with dynamic one, so
>>>>> now SRS should be always right. This is applicable also for the textures,
>>>>> texture srs value is based in the information received for the WMS
>>>>> GetCabalities request. I was only able to test DEM file since I don't have
>>>>> texture available which you are using. I would have been used your running
>>>>> test server, but since it's lacking cross-origin resource sharing it is not
>>>>> possible.
>>>>>
>>>>> DEM file which I used:
>>>>> ftp://ftp.geo.euskadi.net/lidar/MDE_LIDAR_2013_ETRS89/MDT_LIDAR_2013_25m_ETRS89.zip
>>>>>
>>>>> Changes are uploaded to the github, so you can check if changes are
>>>>> helpful for you. In geoserver I defined EPSG:25830 as declared SRS. I also
>>>>> did set "Declared SRS handling" to "reproject native to declared".
>>>>>
>>>>> Best regards,
>>>>> Sami
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Aug 4, 2015 at 1:16 PM, Ibon Salbidegoitia <
>>>>> ibon.salbi at gmail.com> wrote:
>>>>>
>>>>>> Hi Juha and Sami,
>>>>>>
>>>>>> Taking into account your comment 2, I have modified the source of scenemngr.js
>>>>>> file to make it more general and change the srs variable declaration
>>>>>> to: var srs = "&srs=" + TerrainTextureCRS;
>>>>>> This makes the srs to be always the same of the layer that it you are
>>>>>> loading.
>>>>>> You can check it here:
>>>>>> http://151.80.143.120/GIS_4.3.3_MfE/GIS_Client_DEM/index.xhtml
>>>>>> * I added a console log on that line (257) to show it:
>>>>>> console.log("srs: ", srs);
>>>>>>
>>>>>> However, when loading ODE data I introduced, there is an error on
>>>>>> line 477 of scenemngr.js (use browser debug tools to check it) and the
>>>>>> previous "s", "t", "avg dist in s" and "avg dist in t" variables on
>>>>>> console log show me that as told you on the previous email, that something
>>>>>> with the NO-DATA information or something else is going wrong (NoData
>>>>>> Value=-3.4028234663852886e+38).
>>>>>> "s" and "t" are not equal values on my layers (ODE) as they are on
>>>>>> the test client default layers. Which is themeaning of this information and
>>>>>> where is the problem?
>>>>>>
>>>>>> You also mentioned on your comment 3 that the terrain and texture
>>>>>> have to be in the same SRS. Does it correct? If so, please let me know to
>>>>>> change it and test it.
>>>>>>
>>>>>> Thank you in advance. Best regards,
>>>>>>
>>>>>> Ibon
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2015-07-27 12:58 GMT+00:00 Juha Hyvärinen <
>>>>>> juha.hyvarinen at cyberlightning.com>:
>>>>>>
>>>>>>> Hi Ibon,
>>>>>>>
>>>>>>> Here's what I found out about your reported problems.
>>>>>>>
>>>>>>> 1. I lookd into your test data and elevation data seemed to be
>>>>>>> correct. Since all customer level monitors can only show 8 bit colors,
>>>>>>> previewing image with higher color depth will be normalized to 8 bit images
>>>>>>> and all color values are recomputed to that scale. When you zoom into
>>>>>>> "white" only are, you will see more details also in preview window. You can
>>>>>>> also view raw pixel values just by clicking a spot you want more info from.
>>>>>>>
>>>>>>> 2. I noticed that srs value is hard coded into demo client code and
>>>>>>> therefor it's incorrect for your dataset.
>>>>>>> It is defined in scenemngr.js file in line 257: var srs =
>>>>>>> "&srs=EPSG:3067";
>>>>>>> For your data it should be: var srs = "&srs=EPSG:25830"
>>>>>>>
>>>>>>> I haven't worked with current demo client code, so I'm not sure how
>>>>>>> that part of code could be made more dynamic and I'm also not sure if Sami
>>>>>>> will have time for that after he returns from his vacation. For now quick
>>>>>>> fix is to change that value to code. It's also worth to note that demo
>>>>>>> client is delivered only for demonstration purposes and therefore it's not
>>>>>>> guaranteed to work with all possible datasets.
>>>>>>>
>>>>>>> 3. Problem with textures not showing could be related to the fact
>>>>>>> that terrain and texture are defined in different coordinate systems and
>>>>>>> client is not able to handle that situation. As noted earlier I'm not
>>>>>>> familiar with client code and debugging that will take some time. From the
>>>>>>> server side everything seems to be just fine.
>>>>>>>
>>>>>>> - Juha
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jul 27, 2015 at 11:24 AM, Ibon Salbi <ibon.salbi at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Juha,
>>>>>>>>
>>>>>>>> Thank you. If you have any problem or doubts about my explanations,
>>>>>>>> do not hesitate to ask me whatever you need to be clarified.
>>>>>>>> Kind regards,
>>>>>>>>
>>>>>>>> Ibon
>>>>>>>>
>>>>>>>>
>>>>>>>> El 27/07/2015, a las 07:58, Juha Hyvärinen <
>>>>>>>> juha.hyvarinen at cyberlightning.com> escribió:
>>>>>>>>
>>>>>>>> Hi Ibon,
>>>>>>>>
>>>>>>>> I just returned from my summer vacation and I will look into that
>>>>>>>> problem as soon as it's possible.
>>>>>>>>
>>>>>>>> - Juha
>>>>>>>>
>>>>>>>> On Mon, Jul 13, 2015 at 2:16 PM, Ibon Salbidegoitia <
>>>>>>>> ibon.salbi at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Juha,
>>>>>>>>>
>>>>>>>>> I have seen from an automatic reply email that Sami is going to be
>>>>>>>>> on holidays till 31st of July. Is there any other technical support who can
>>>>>>>>> give me feedback about the Fiware Enabler developed by Cyberlightning?
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> Ibon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2015-07-13 11:10 GMT+00:00 Ibon Salbidegoitia <
>>>>>>>>> ibon.salbi at gmail.com>:
>>>>>>>>>
>>>>>>>>>> Hi Sami,
>>>>>>>>>>
>>>>>>>>>> I haven't received reply for the issue I told you in my previous
>>>>>>>>>> email.
>>>>>>>>>> Can you please confirm me that you received? If so, can you tell
>>>>>>>>>> me the situation?
>>>>>>>>>> Should I put Juha in Cc for all this process?
>>>>>>>>>> Thank you in advance. Best regards,
>>>>>>>>>>
>>>>>>>>>> Ibon
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2015-07-01 17:20 GMT+00:00 Ibon Salbidegoitia <
>>>>>>>>>> ibon.salbi at gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> Hi Sami,
>>>>>>>>>>>
>>>>>>>>>>> First of all, as I mentioned in a previous email, I have put in
>>>>>>>>>>> Cc our Fiware Accelerator (Finodex) coaches as they requested in a meeting
>>>>>>>>>>> with them to follow the situation of each project that they are supporting.
>>>>>>>>>>>
>>>>>>>>>>> About your previous email, the last release is working! I have
>>>>>>>>>>> test it in our test server (http://151.80.143.120/GIS_4.3.3/)
>>>>>>>>>>> and the DEM works with the data provided as test.
>>>>>>>>>>> I have checked that the test requires the textures to have
>>>>>>>>>>> "texture" on their names and "DEM" for terrain DEM. I have upload my data
>>>>>>>>>>> to test it but I have the following problems:
>>>>>>>>>>>
>>>>>>>>>>> 1. When I preview your DEM (DEM_geotiff_terrain_EPSG3067) I
>>>>>>>>>>> can see on geoserver a grayscale image on openlayers (openlayers
>>>>>>>>>>> example
>>>>>>>>>>> <http://151.80.143.120:8080/geoserver/fiware/wms?service=WMS&version=1.1.0&request=GetMap&layers=fiware:DEM_geotiff_terrain_EPSG3067&styles=&bbox=374010.0,7547990.0,380020.0,7554000.0&width=512&height=512&srs=EPSG:3067&format=application/openlayers>
>>>>>>>>>>> ).
>>>>>>>>>>>
>>>>>>>>>>> I have seen that the tiff is a float32 image in grayscale
>>>>>>>>>>> with a 281.604 minimum value and 792.834 maximum value .
>>>>>>>>>>>
>>>>>>>>>>> I have upload a similar DEM called "DEM_ODE_terrain" that it
>>>>>>>>>>> can be selected from the DEM GIS Client example (on previous link). This
>>>>>>>>>>> image is also float32 tiff with a minimum value of -3.40282e+38 and maximum
>>>>>>>>>>> of 1545.84, where minimum value is a NoData value as it is shown with
>>>>>>>>>>> gdalinfo command: NoData Value=-3.4028234663852886e+38
>>>>>>>>>>> The TIF image I use it can be found here:
>>>>>>>>>>> ftp://ftp.geo.euskadi.net/lidar/MDE_LIDAR_2013_ETRS89/MDT_LIDAR_2013_25m_ETRS89.zip
>>>>>>>>>>> The geodesic system of this TIF is ETRS89 that correponds to
>>>>>>>>>>> SRS EPSG:25830. However the preview seems to be a 0-1 grayscale image as
>>>>>>>>>>> you can see here
>>>>>>>>>>> <http://151.80.143.120:8080/geoserver/fiware/wms?service=WMS&version=1.1.0&request=GetMap&layers=fiware:DEM_ODE_terrain&styles=&bbox=461050.0,4700750.0,606500.0,4811750.0&width=512&height=390&srs=EPSG:25830&format=application/openlayers> (takes
>>>>>>>>>>> some seconds as it is big). This could be due to the NoData
>>>>>>>>>>> values that make range so big not taking into account that the data does
>>>>>>>>>>> not exist. This is correct?
>>>>>>>>>>>
>>>>>>>>>>> 2. The Terrain texture also has been uploaded to Geoserver
>>>>>>>>>>> as can be seen here
>>>>>>>>>>> <http://151.80.143.120:8080/geoserver/fiware/wms?service=WMS&version=1.1.0&request=GetMap&layers=fiware:ODE_terrain_texture_orto&styles=&bbox=-3.480675981601883,42.457568610196404,-1.6858572736097794,43.45901565397562&width=591&height=330&srs=EPSG:4326&format=application/openlayers>
>>>>>>>>>>> .
>>>>>>>>>>> The DEM testing client gives the oportunity to select both
>>>>>>>>>>> layers mentioned (for terrain DEM + terrain texture), however nothing
>>>>>>>>>>> appears, only one small gray square looking upwards (on zenith) with the
>>>>>>>>>>> camera on the client as the altitudes are higher than the ones from the
>>>>>>>>>>> examples.
>>>>>>>>>>>
>>>>>>>>>>> So everything from test seems to work correctly, but when I
>>>>>>>>>>> introduce my data, the DEM test client does not seem to work.
>>>>>>>>>>> Could it be due to NoData values? Anyway, why the ortophoto
>>>>>>>>>>> inserted is shown as gray layer?
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Ibon
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2015-06-30 11:33 GMT+00:00 Sami J <
>>>>>>>>>>> sami.jylkka at cyberlightning.com>:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Ibon,
>>>>>>>>>>>> sorry about late response. We have now made new release from
>>>>>>>>>>>> both server and example client, these can be found from the forge under *MIWI-GISDataProvider
>>>>>>>>>>>> 4.3.3*-release: https://forge.fiware.org/frs/?group_id=7
>>>>>>>>>>>> source code has been uploaded also to the github.
>>>>>>>>>>>>
>>>>>>>>>>>> Short documentation related using DEM images can be found from:
>>>>>>>>>>>> http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/GIS_Data_Provider_-_User_and_Programmers_Guide#World_Wind_Format_Module
>>>>>>>>>>>>
>>>>>>>>>>>> Installation document covers how to upload DEM image to
>>>>>>>>>>>> geoserver:
>>>>>>>>>>>> http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/GIS_Data_Provider_-_Installation_and_Administration_Guide#GeoTIFF_based_.28DEM.29_data_sets_for_elevation
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regarding using latitude/longitude coordinates, I don't know if
>>>>>>>>>>>> you are using them or not. I just wanted to mention this if you haven't
>>>>>>>>>>>> noticed this information from the GIS GE documentation :) To elaborate
>>>>>>>>>>>> further, provided GIS GE example web client has been implemented so that it
>>>>>>>>>>>> works correctly only with metric coordinate system. Using lat/long data
>>>>>>>>>>>> source won't work with the provided client, and that's why lat/long
>>>>>>>>>>>> coordinate handling needs to be implemented by yourself. But as said, I
>>>>>>>>>>>> don't know if you are using data source based in latitude/longitudes or
>>>>>>>>>>>> metric coordinates.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Sami
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jun 25, 2015 at 11:53 AM, Ibon Salbidegoitia <
>>>>>>>>>>>> ibon.salbi at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Sami,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have a couple of things to ask.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. It is great that the grayscale images for elevation is
>>>>>>>>>>>>> pretty much ready. Can you tell me when do you expect to finish the test
>>>>>>>>>>>>> and when I can be able to test it?
>>>>>>>>>>>>> 2. About the last paragraph, I do not understand why you
>>>>>>>>>>>>> tell me that lat/long is not supported. Where I have used it? Do you refer
>>>>>>>>>>>>> to the bounding box of the layers I have upload? So do I have to change the
>>>>>>>>>>>>> SRS to EPSG:25830 for example instead of EPSG:4326?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Ibon
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2015-06-24 14:22 GMT+00:00 Sami J <
>>>>>>>>>>>>> sami.jylkka at cyberlightning.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Ibon,
>>>>>>>>>>>>>> ok now it's clear; in a short problem is that elevation data
>>>>>>>>>>>>>> in grayscale image is not yet supported by the GIS GE.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The good thing is that implementation for it is pretty much
>>>>>>>>>>>>>> ready, we are doing final testing for it and then documentation will be
>>>>>>>>>>>>>> updated. So soon it is possible to use grayscale elevation images as for
>>>>>>>>>>>>>> source to elevation data, GIS GE implementation supports same data format
>>>>>>>>>>>>>> as SRTM data uses. GIS GE will send response data in octet-stream format,
>>>>>>>>>>>>>> client itself needs to create 3D objects based on the octet-stream data.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> please note that current version of the GIS GE reference web
>>>>>>>>>>>>>> client only supports metric coordinates, Lat/log is not working. I mention
>>>>>>>>>>>>>> this because if you'd like to use GIS data in Lat/Log format, the client
>>>>>>>>>>>>>> scenemanager logic needs to be re-implemented.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Sami
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jun 24, 2015 at 10:10 AM, Ibon Salbidegoitia <
>>>>>>>>>>>>>> ibon.salbi at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Sami,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have upload the ortophoto on "fiware" workspace and also
>>>>>>>>>>>>>>> texture with appropriate names to be able to see them in my Client examples:
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> http://151.80.143.120/GIS_4.3.2/GIS_Client_octet-stream/index.xhtml
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> http://151.80.143.120/GIS_4.3.2/GIS_Client_xml3d/index.xhtml
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> As you will see, selecting the terrain texture, the new
>>>>>>>>>>>>>>> layer appears (surprisingly, the one of other workspace also). But if I try
>>>>>>>>>>>>>>> to select the terrain layer (first box of GIS client), you will see that
>>>>>>>>>>>>>>> the one uploaded with the name "ODE_test_terrain" does not appear. Maybe I
>>>>>>>>>>>>>>> didn't explain correctly in my previous email, but this layer is the
>>>>>>>>>>>>>>> altitude layer, the shape. So I suppose that the W3DS options have to be
>>>>>>>>>>>>>>> defined, but if you access to that layer on our testing server (
>>>>>>>>>>>>>>> http://151.80.143.120:8080/geoserver . User: admin Pass:
>>>>>>>>>>>>>>> geoserver) you will see that I cannot access to the W3DS tab of "ODE_test_terrain"
>>>>>>>>>>>>>>> layer to make it "Active" and "Queryable" and maybe other options required
>>>>>>>>>>>>>>> on the GIS client to be able to require it as the shape of the terrain.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which could be the problem?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Just one more thing. I am selected on one of the FIWARE
>>>>>>>>>>>>>>> accelerators (Finodex) to develop services with Fiware tools. As you
>>>>>>>>>>>>>>> imagine, this enabler is one that I am using. They required me to put them
>>>>>>>>>>>>>>> (fiware coaches of Finodex accelerator) in CC on this discussion emails to
>>>>>>>>>>>>>>> follow the evolution of our project. So I will put them in CC on the next
>>>>>>>>>>>>>>> email. I suppose there is no problem on this, is it?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Ibon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2015-06-23 8:38 GMT+02:00 Sami J <
>>>>>>>>>>>>>>> sami.jylkka at cyberlightning.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Ibon,
>>>>>>>>>>>>>>>> thank you for the feedback, I need to update user guide
>>>>>>>>>>>>>>>> about this issue. Textures are queried via geoserver's WMS-interface. This
>>>>>>>>>>>>>>>> interface isn't related to W3DS-module and therefore
>>>>>>>>>>>>>>>> there's no need to declare W3DS related options for the
>>>>>>>>>>>>>>>> texture layer. So when you define texture layer which you want to use as a
>>>>>>>>>>>>>>>> texture for 3D terrain, it is enough to define options under "Data"-tab.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>> Sami
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Jun 22, 2015 at 6:21 PM, Ibon Salbidegoitia <
>>>>>>>>>>>>>>>> ibon.salbi at gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Sami,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank you. Yes I knew that because I saw it in the JS code
>>>>>>>>>>>>>>>>> you mention.
>>>>>>>>>>>>>>>>> I was going to change the ortophoto and texture to
>>>>>>>>>>>>>>>>> workspace to "fiware" for that reason, but being honest I didn't test it
>>>>>>>>>>>>>>>>> because I found the error I described in my previous email. I mean, I was
>>>>>>>>>>>>>>>>> trying to access the texture layer W3DS tab to make it "Active" and
>>>>>>>>>>>>>>>>> "Queryable" as required on the wiki, so that's the reason I sent you the
>>>>>>>>>>>>>>>>> error, because I though that it wouldn't be possible to go ahead without
>>>>>>>>>>>>>>>>> changing the texture the configuration.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, if I am wrong and it is not necessary to configure the
>>>>>>>>>>>>>>>>> W3DS tab, I will try it. I don't need from you to change the JS code to
>>>>>>>>>>>>>>>>> find texture and photos of all the workspace. I will change the data to
>>>>>>>>>>>>>>>>> "fiware" workspae.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I will tell you if everything goes well.
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ibon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2015-06-22 9:05 GMT+02:00 Sami J <
>>>>>>>>>>>>>>>>> sami.jylkka at cyberlightning.com>:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Ibon,
>>>>>>>>>>>>>>>>>> nice to hear you have been able to progress in your work!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Let me answer behalf Juha: Your texture data seems to be
>>>>>>>>>>>>>>>>>> ok. In case you are using GIS GE reference client problem with the texture
>>>>>>>>>>>>>>>>>> loading might be with the used workspace. GIS GE reference client assumes
>>>>>>>>>>>>>>>>>> that all data is in "fiware"-workspace. This applies also for the textures.
>>>>>>>>>>>>>>>>>> So changing texture workspace to "fiware" might solve loading problem.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If you'd like to modify reference client to support also
>>>>>>>>>>>>>>>>>> other workspaces, URI for texture loading is defined in the scenemngr.js
>>>>>>>>>>>>>>>>>> getElements-function. You can modify URL created in there.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>> Sami
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Jun 22, 2015 at 9:05 AM, Juha Hyvärinen <
>>>>>>>>>>>>>>>>>> juha.hyvarinen at cyberlightning.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>>>>>>> From: Ibon Salbidegoitia <ibon.salbi at gmail.com>
>>>>>>>>>>>>>>>>>>> Date: Thu, Jun 18, 2015 at 11:05 AM
>>>>>>>>>>>>>>>>>>> Subject: Re: W3DS - FIWARE
>>>>>>>>>>>>>>>>>>> To: Juha Hyvärinen <juha.hyvarinen at cyberlightning.com>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Juha,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I checked that many changes where done on the data and
>>>>>>>>>>>>>>>>>>> wiki. Congratulations! Now everything is very clear!
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I write you because I have some doubts about the texture
>>>>>>>>>>>>>>>>>>> data. On the wiki "User and Programmers Guide" section "3.3.3 Adding
>>>>>>>>>>>>>>>>>>> texture" the last sentence says that one option is to store texture on a
>>>>>>>>>>>>>>>>>>> GeoTIFF.
>>>>>>>>>>>>>>>>>>> I used the following GeoTIFF texture (MDT) data on
>>>>>>>>>>>>>>>>>>> float32 format to try it. You can download it here:
>>>>>>>>>>>>>>>>>>> ftp://ftp.geo.euskadi.net/lidar/MDE_LIDAR_2013_ETRS89/MDT_LIDAR_2013_25m_ETRS89.zip
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The file has been uploaded to Geoserver. As it does not
>>>>>>>>>>>>>>>>>>> recognize the SRS, I defined whichis the EPSG:25830.
>>>>>>>>>>>>>>>>>>> As it says in the Unit Testing Plan, I have to go to
>>>>>>>>>>>>>>>>>>> W3DS tab to activate and make it queryable.
>>>>>>>>>>>>>>>>>>> However, it returns an error on JIRA.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You can check it in our geoserver:
>>>>>>>>>>>>>>>>>>> http://151.80.143.120:8080/geoserver/
>>>>>>>>>>>>>>>>>>> + User: admin
>>>>>>>>>>>>>>>>>>> + Pass: geoserver
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The GeoTIFF texture is defined on the layer "terrain" ,
>>>>>>>>>>>>>>>>>>> on workspace "ODE"
>>>>>>>>>>>>>>>>>>> Please let me know why this option is not available.
>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ibon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2015-06-02 18:20 GMT+02:00 Ibon Salbidegoitia <
>>>>>>>>>>>>>>>>>>> ibon.salbi at gmail.com>:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi Juha,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I have been able to run GIS Client examples:
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> http://151.80.143.120/GIS_4.3.2/GIS_Client_octet-stream/index.xhtml
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> http://151.80.143.120/GIS_4.3.2/GIS_Client_xml3d/index.xhtml
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> As you can see in the attached pictures, there seems to
>>>>>>>>>>>>>>>>>>>> be some problems with space between layers and I cannot see the xml3d
>>>>>>>>>>>>>>>>>>>> buildings on the examples.
>>>>>>>>>>>>>>>>>>>> Do you know where the buildings should appear?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Just as comment, I have found more bugs that may
>>>>>>>>>>>>>>>>>>>> improve the Unit Testing Plan. I list all of them below if you are
>>>>>>>>>>>>>>>>>>>> interested on changing them
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *On wiki*:
>>>>>>>>>>>>>>>>>>>> 1.2.2.4 PostGIS connection to GeoServer
>>>>>>>>>>>>>>>>>>>> + When Publish fiware_test_terrain PostGIS - PostGIS
>>>>>>>>>>>>>>>>>>>> Database
>>>>>>>>>>>>>>>>>>>> In "Objects Attributes" section select "name" for
>>>>>>>>>>>>>>>>>>>> the "Object ID" it is not possible because only options are [elevation /
>>>>>>>>>>>>>>>>>>>> geom / lod]. The documentation seems to need to select "name" when it does
>>>>>>>>>>>>>>>>>>>> not exist.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1.2.3.2 terrain_texture_orto.tif and
>>>>>>>>>>>>>>>>>>>> terrain_texture_raster.tif
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> + Raster_map_image_for_terrain_texture/terrain_texture_raster.tif
>>>>>>>>>>>>>>>>>>>> SRS is automatically set to EPSG:404000. Not
>>>>>>>>>>>>>>>>>>>> EPSG:3067 as it is said on the wiki
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> + Aero_photo_for_terrain_texture/terrain_texture_orto.tif
>>>>>>>>>>>>>>>>>>>> SRS is automatically set to EPSG:3067. Not EPSG:
>>>>>>>>>>>>>>>>>>>> 404000 as it is said on the wiki
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *On GIS Client*:
>>>>>>>>>>>>>>>>>>>> Version 4.3.2
>>>>>>>>>>>>>>>>>>>> + The both examples () have changed the script
>>>>>>>>>>>>>>>>>>>> "map.js" and now it is not automatically defined "baseUrl" variable as
>>>>>>>>>>>>>>>>>>>> previous version 4.2.2. It will be recommended to use the code lines:
>>>>>>>>>>>>>>>>>>>> var ip = location.host;
>>>>>>>>>>>>>>>>>>>> var baseUrl = "http://"+ip+"/geoserver/";
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *On MIWI-GISDataProvider download section*:
>>>>>>>>>>>>>>>>>>>> + Version 4.3.2
>>>>>>>>>>>>>>>>>>>> - Test assest 4.3.2 ZIP file has a space between
>>>>>>>>>>>>>>>>>>>> text and version numbers ->
>>>>>>>>>>>>>>>>>>>> https://forge.fiware.org/frs/download.php/1645/Test_asset_%204.3.2.zip
>>>>>>>>>>>>>>>>>>>> - ZIP file when decompressed has a folder with a
>>>>>>>>>>>>>>>>>>>> space between text ("rel") and numbers ("4.3.2") -> rel\
>>>>>>>>>>>>>>>>>>>> 4.3.2
>>>>>>>>>>>>>>>>>>>> - Subfolders of Test_assest "Building_coordinates
>>>>>>>>>>>>>>>>>>>> /" and "PostGIS_database_backup /" have a space at the end of the name.
>>>>>>>>>>>>>>>>>>>> + Version 4.2.2
>>>>>>>>>>>>>>>>>>>> - Subfolders of Test_assest "Building_coordinates
>>>>>>>>>>>>>>>>>>>> /" and "PostGIS_database_backup /" have a space at the end of the name.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ibon
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2015-06-02 11:59 GMT+00:00 Juha Hyvärinen <
>>>>>>>>>>>>>>>>>>>> juha.hyvarinen at cyberlightning.com>:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi Ibon,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thank you for feedback about test asset naming
>>>>>>>>>>>>>>>>>>>>> problems, I wasn't aware of those and I have informed my colleague who have
>>>>>>>>>>>>>>>>>>>>> made those packages. He will fix those tomorrow.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Building coordinates are needed if you want to use
>>>>>>>>>>>>>>>>>>>>> external 3D models in your application with real spatial information. For
>>>>>>>>>>>>>>>>>>>>> example hand made building models placed in correct position etc. If you
>>>>>>>>>>>>>>>>>>>>> don't need those then that step is optional.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We also updated guide for database restoring and it
>>>>>>>>>>>>>>>>>>>>> can be found from here:
>>>>>>>>>>>>>>>>>>>>> https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/GIS_Data_Provider_-_Unit_Testing_Plan#Import_PostGIS_database_backup_with_terrain_data
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Your problem was that username in the database backup
>>>>>>>>>>>>>>>>>>>>> was defined to be 'sami' and it does not exist in your system. It is fixed
>>>>>>>>>>>>>>>>>>>>> by ignoring username from the database backup.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Before restoring that database backup you should drop
>>>>>>>>>>>>>>>>>>>>> fiware_test_terrain table.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Let me know if this was helpful.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - Juha
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Tue, Jun 2, 2015 at 11:41 AM, Ibon Salbidegoitia <
>>>>>>>>>>>>>>>>>>>>> ibon.salbi at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Sorry I send previous email without finishing the
>>>>>>>>>>>>>>>>>>>>>> email as error. You have below all the email.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi Juha,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Sorry for the delay, I was busy and these last 3 days
>>>>>>>>>>>>>>>>>>>>>> I had some problems with tomcat so I decided to format everything and start
>>>>>>>>>>>>>>>>>>>>>> from the beginning to know what errors are happening.
>>>>>>>>>>>>>>>>>>>>>> I will try to explain cronologically all the steps
>>>>>>>>>>>>>>>>>>>>>> and error/bugs found.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> First of all I update git repository and change to
>>>>>>>>>>>>>>>>>>>>>> the "fiware_rel_4.x" branch to create the WAR file with the maven
>>>>>>>>>>>>>>>>>>>>>> command: mvn install -DdownloadSources=true -DskipTests=true -Pw3ds
>>>>>>>>>>>>>>>>>>>>>> After restarting tomcat, the geoserver seems to work
>>>>>>>>>>>>>>>>>>>>>> -> http://151.80.143.120:8080/geoserver (User:
>>>>>>>>>>>>>>>>>>>>>> admin / Pass: geoserver)
>>>>>>>>>>>>>>>>>>>>>> I did not use the WAR published, I created my own
>>>>>>>>>>>>>>>>>>>>>> from the new github branch as you see.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So then I decided to update the test unit plan. Here
>>>>>>>>>>>>>>>>>>>>>> I have one comment just to improve in case you want. I have checked that
>>>>>>>>>>>>>>>>>>>>>> you usually use "space" on folders and files which usually is no suitable.
>>>>>>>>>>>>>>>>>>>>>> I refer specificly to the 4.3.2 version.
>>>>>>>>>>>>>>>>>>>>>> + The ZIP file has a "space" on the name what
>>>>>>>>>>>>>>>>>>>>>> requires to use ASCI character to download: wget --no-check-certificate
>>>>>>>>>>>>>>>>>>>>>> https://forge.fiware.org/frs/download.php/1645/Test_asset_%204.3.2.zip
>>>>>>>>>>>>>>>>>>>>>> + When ZIP is decompressed, the name of the folder
>>>>>>>>>>>>>>>>>>>>>> has also a "space": /home/UnitTestPlan/rel\ 4.3.2
>>>>>>>>>>>>>>>>>>>>>> + PostGIS database backup has also a "space" at
>>>>>>>>>>>>>>>>>>>>>> the end: /home/UnitTestPlan/rel\ 4.3.2/PostGIS_database_backup\ /
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Any way, I continue with the database restore. On the
>>>>>>>>>>>>>>>>>>>>>> PostGIS database backup, I checked on the 4.3.2 version that there are 2
>>>>>>>>>>>>>>>>>>>>>> files: building_coordinates and test_asset-terrain.
>>>>>>>>>>>>>>>>>>>>>> The "building_coordinates" file appears to be a text
>>>>>>>>>>>>>>>>>>>>>> format dump. So is this file necessary to upload to database?
>>>>>>>>>>>>>>>>>>>>>> The "test_asset-terrain" could be uploaded to
>>>>>>>>>>>>>>>>>>>>>> postgres with the following command: pg_restore -d fiware_test
>>>>>>>>>>>>>>>>>>>>>> /home/UnitTestPlan/rel\ 4.3.2/PostGIS_database_backup\
>>>>>>>>>>>>>>>>>>>>>> /FIWARE-postgis-test_asset-terrain
>>>>>>>>>>>>>>>>>>>>>> However, I receive the following errors:
>>>>>>>>>>>>>>>>>>>>>> =================================================
>>>>>>>>>>>>>>>>>>>>>> pg_restore: [archiver (db)] Error while PROCESSING
>>>>>>>>>>>>>>>>>>>>>> TOC:
>>>>>>>>>>>>>>>>>>>>>> pg_restore: [archiver (db)] Error from TOC entry 184;
>>>>>>>>>>>>>>>>>>>>>> 1259 65659 TABLE fiware_test_terrain sami
>>>>>>>>>>>>>>>>>>>>>> pg_restore: [archiver (db)] could not execute query:
>>>>>>>>>>>>>>>>>>>>>> ERROR: role "sami" does not exist
>>>>>>>>>>>>>>>>>>>>>> Command was: ALTER TABLE public.fiware_test_terrain
>>>>>>>>>>>>>>>>>>>>>> OWNER TO sami;
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> pg_restore: [archiver (db)] Error from TOC entry 183;
>>>>>>>>>>>>>>>>>>>>>> 1259 65657 SEQUENCE fiware_test_terrain_id_seq sami
>>>>>>>>>>>>>>>>>>>>>> pg_restore: [archiver (db)] could not execute query:
>>>>>>>>>>>>>>>>>>>>>> ERROR: role "sami" does not exist
>>>>>>>>>>>>>>>>>>>>>> Command was: ALTER TABLE
>>>>>>>>>>>>>>>>>>>>>> public.fiware_test_terrain_id_seq OWNER TO sami;
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> WARNING: errors ignored on restore: 2
>>>>>>>>>>>>>>>>>>>>>> =================================================
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I checked the information stored from backup on the
>>>>>>>>>>>>>>>>>>>>>> database and found the following tables, which I am not sure if they are
>>>>>>>>>>>>>>>>>>>>>> all or there are some missing.
>>>>>>>>>>>>>>>>>>>>>> =================================================
>>>>>>>>>>>>>>>>>>>>>> List of relations
>>>>>>>>>>>>>>>>>>>>>> Schema | Name | Type |
>>>>>>>>>>>>>>>>>>>>>> Owner
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --------+----------------------------+----------+----------
>>>>>>>>>>>>>>>>>>>>>> public | fiware_test_terrain | table |
>>>>>>>>>>>>>>>>>>>>>> postgres
>>>>>>>>>>>>>>>>>>>>>> public | fiware_test_terrain_id_seq | sequence |
>>>>>>>>>>>>>>>>>>>>>> postgres
>>>>>>>>>>>>>>>>>>>>>> public | geography_columns | view |
>>>>>>>>>>>>>>>>>>>>>> postgres
>>>>>>>>>>>>>>>>>>>>>> public | geometry_columns | view |
>>>>>>>>>>>>>>>>>>>>>> postgres
>>>>>>>>>>>>>>>>>>>>>> public | raster_columns | view |
>>>>>>>>>>>>>>>>>>>>>> postgres
>>>>>>>>>>>>>>>>>>>>>> public | raster_overviews | view |
>>>>>>>>>>>>>>>>>>>>>> postgres
>>>>>>>>>>>>>>>>>>>>>> public | spatial_ref_sys | table |
>>>>>>>>>>>>>>>>>>>>>> postgres
>>>>>>>>>>>>>>>>>>>>>> =================================================
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I did not continue because it seems that there are
>>>>>>>>>>>>>>>>>>>>>> some errors that I should first understand and fix before continuing.
>>>>>>>>>>>>>>>>>>>>>> If you need something else from my side, please let
>>>>>>>>>>>>>>>>>>>>>> me know. And please, let me know if I have done something wrong.
>>>>>>>>>>>>>>>>>>>>>> Thank you. Best regards,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ibon
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2015-06-02 8:33 GMT+00:00 Ibon Salbidegoitia <
>>>>>>>>>>>>>>>>>>>>>> ibon.salbi at gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi Juha,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sorry for the delay, I was busy and these last 3
>>>>>>>>>>>>>>>>>>>>>>> days I had some problems with tomcat so I decided to format everything and
>>>>>>>>>>>>>>>>>>>>>>> start from the beginning to know what errors are happening.
>>>>>>>>>>>>>>>>>>>>>>> I will try to explain cronologically all the steps
>>>>>>>>>>>>>>>>>>>>>>> and error/bugs found.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> First of all I update git repository and change to
>>>>>>>>>>>>>>>>>>>>>>> the "fiware_rel_4.x" branch to create the WAR file with the maven
>>>>>>>>>>>>>>>>>>>>>>> command: mvn install -DdownloadSources=true -DskipTests=true -Pw3ds
>>>>>>>>>>>>>>>>>>>>>>> After restarting tomcat, the geoserver seems to work
>>>>>>>>>>>>>>>>>>>>>>> -> http://151.80.143.120:8080/geoserver (User:
>>>>>>>>>>>>>>>>>>>>>>> admin / Pass: geoserver)
>>>>>>>>>>>>>>>>>>>>>>> I did not use the WAR published, I created my own
>>>>>>>>>>>>>>>>>>>>>>> from the new github branch as you see.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> So then I decided to update the test unit plan. Here
>>>>>>>>>>>>>>>>>>>>>>> I have one comment just to improve in case you want. I have checked that
>>>>>>>>>>>>>>>>>>>>>>> you usually use "space" on folders and files which usually is no suitable.
>>>>>>>>>>>>>>>>>>>>>>> I refer specificly to the 4.3.2 version.
>>>>>>>>>>>>>>>>>>>>>>> + The ZIP file has a "space" on the name what
>>>>>>>>>>>>>>>>>>>>>>> requires to use ASCI character to download: wget --no-check-certificate
>>>>>>>>>>>>>>>>>>>>>>> https://forge.fiware.org/frs/download.php/1645/Test_asset_%204.3.2.zip
>>>>>>>>>>>>>>>>>>>>>>> + When ZIP is decompressed, the name of the
>>>>>>>>>>>>>>>>>>>>>>> folder has also a "space": /home/UnitTestPlan/rel\ 4.3.2
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 2015-05-26 12:49 GMT+00:00 Juha Hyvärinen <
>>>>>>>>>>>>>>>>>>>>>>> juha.hyvarinen at cyberlightning.com>:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hi Ibon,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> That problem should now be fixed, code is in the
>>>>>>>>>>>>>>>>>>>>>>>> github (
>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/Cyberlightning/geoserver/tree/fiware_rel_4.x)
>>>>>>>>>>>>>>>>>>>>>>>> and we have also published new war file in Fiware FusionForge (
>>>>>>>>>>>>>>>>>>>>>>>> https://forge.fiware.org/frs/download.php/1643/geoserver.war
>>>>>>>>>>>>>>>>>>>>>>>> ).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We also updated test assets and reference client.
>>>>>>>>>>>>>>>>>>>>>>>> Updated reference client is already available from the Github and test
>>>>>>>>>>>>>>>>>>>>>>>> assets will be published later today or tomorrow morning to FusionForge
>>>>>>>>>>>>>>>>>>>>>>>> under release 4.3.2 (
>>>>>>>>>>>>>>>>>>>>>>>> https://forge.fiware.org/frs/?group_id=7).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I hope that this release will fix problems you
>>>>>>>>>>>>>>>>>>>>>>>> encountered earlier. Please report back did this solve those problems.
>>>>>>>>>>>>>>>>>>>>>>>> Thank you for submitting these bug reports.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - Juha
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Tue, May 26, 2015 at 9:33 AM, Juha Hyvärinen <
>>>>>>>>>>>>>>>>>>>>>>>> juha.hyvarinen at cyberlightning.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ibon,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We have looked into that problem now for couple of
>>>>>>>>>>>>>>>>>>>>>>>>> days and it seems to be somehow related to Tomcat and system locale
>>>>>>>>>>>>>>>>>>>>>>>>> settings. We can reproduce same problem when we deploy to a Tomcat instance
>>>>>>>>>>>>>>>>>>>>>>>>> while with Jetty everything works just fine.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I'm working with the fix now, but there is also a
>>>>>>>>>>>>>>>>>>>>>>>>> workaround: deploy war package to a Jetty instance.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I will notify you once I have pushed code changes
>>>>>>>>>>>>>>>>>>>>>>>>> to git.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> - Juha
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 22, 2015 at 1:08 PM, Juha Hyvärinen <
>>>>>>>>>>>>>>>>>>>>>>>>> juha.hyvarinen at cyberlightning.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I also forgot to mention that you should move to
>>>>>>>>>>>>>>>>>>>>>>>>>> newer test client which we will release officially during summer, but code
>>>>>>>>>>>>>>>>>>>>>>>>>> is already available from the Github:
>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/Cyberlightning/Cyber-WeX
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Client code can be found from here:
>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/Cyberlightning/Cyber-WeX/tree/master/GIS/GIS_Client_xml3d
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> - Juha
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 22, 2015 at 12:30 PM, Juha Hyvärinen
>>>>>>>>>>>>>>>>>>>>>>>>>> <juha.hyvarinen at cyberlightning.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ibon,
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I have to admit that I'm clueless with that
>>>>>>>>>>>>>>>>>>>>>>>>>>> terrain problem, since I couldn't replicate it. Everything seems to be
>>>>>>>>>>>>>>>>>>>>>>>>>>> right at the server side but still data is somehow corrupted when it
>>>>>>>>>>>>>>>>>>>>>>>>>>> arrives to the client. We have deployed that same data set without any
>>>>>>>>>>>>>>>>>>>>>>>>>>> problems to more than 20 different systems by many different users during
>>>>>>>>>>>>>>>>>>>>>>>>>>> our internal development and testing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> There are still few points which you could try.
>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Install newer PostGIS version for example
>>>>>>>>>>>>>>>>>>>>>>>>>>> from Ubuntu repositories instead of manually build one.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Try our upcoming release of Geoserver from
>>>>>>>>>>>>>>>>>>>>>>>>>>> Github. This shouldn't be difficult, since you already build your own
>>>>>>>>>>>>>>>>>>>>>>>>>>> version.
>>>>>>>>>>>>>>>>>>>>>>>>>>> If you used git to clone code earlier, you only
>>>>>>>>>>>>>>>>>>>>>>>>>>> need to pull new changes from the repository and change code branch from
>>>>>>>>>>>>>>>>>>>>>>>>>>> fiware to fiware_rel_4.x (git pull && git checkout fiware_rel_4.x) and
>>>>>>>>>>>>>>>>>>>>>>>>>>> rebuild project.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Also I created database dump from building
>>>>>>>>>>>>>>>>>>>>>>>>>>> coordinates table and it's as an attachment. We will add it also to the
>>>>>>>>>>>>>>>>>>>>>>>>>>> assets and update documentation once we have little spare time to do it.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Table can be restored with command: sudo -u postgres psql databasename <
>>>>>>>>>>>>>>>>>>>>>>>>>>> path/to/the/file.sql
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Before restoring that dumb, change URLs in it to
>>>>>>>>>>>>>>>>>>>>>>>>>>> point a place where you actually have that xml file. At the moment URL is
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://localhost/Test_asset/Building_model/building.xml
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> - Juha
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 21, 2015 at 1:09 PM, Ibon
>>>>>>>>>>>>>>>>>>>>>>>>>>> Salbidegoitia <ibon.salbi at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Juha,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You are right, I forgot to edit the tomcat7
>>>>>>>>>>>>>>>>>>>>>>>>>>>> default start-up configuration file.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Now is using openJDK.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2015-05-21 9:36 GMT+00:00 Juha Hyvärinen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> juha.hyvarinen at cyberlightning.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ibon,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Could you restart tomcat again since it still
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses Oracle java 1.8.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - Juha
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 21, 2015 at 10:57 AM, Ibon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Salbidegoitia <ibon.salbi at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Juha,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I checked that tomcat was down due to low xmx
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> size. I restarted and modify xmx to avoid errors.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Asnwering to your comments:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> + Please let me know when you update the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> documentation to check importin building coordinates
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> + I imported with following command of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> postgres:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> $ su - postgres
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> $ createdb fiware_test
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> $ pg_restore -d fiware_test
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ./Test_asset_3.3/PostGIS_database_backup\ /FIWARE-postgis-test_asset
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Because I am using remote server I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot use pgadmin, but the import was correct without errors and I checked
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the data was correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> + I am using Oracle java (1.8.0_31), so I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will change it to openJDK7 as you recommend. Now is changed to openJDK7 to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> version 1.7.0_79
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As I said, the Geoserver is active, so you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can check on it whatever you want.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ibon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2015-05-21 6:56 GMT+00:00 Juha Hyvärinen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> juha.hyvarinen at cyberlightning.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ibon,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I was looking into those errors you reported
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but your server went down before I could figure out any final solution.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Here are m
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Juha Hyvärinen
>>>>>>> Software Engineer
>>>>>>> Cyberlightning Ltd.
>>>>>>>
>>>>>>> email. juha.hyvarinen at cyberlightning.com
>>>>>>>
>>>>>>> See our new press release:
>>>>>>> http://cyberlightning.com/blog/2014/05/13/cyberlightning-brings-3d-visualization-to-industrial-internet-of-things/
>>>>>>>
>>>>>>> www.cyberlightning.com
>>>>>>>
>>>>>>> This e-mail and all attached material are confidential and may
>>>>>>> contain legally privileged information. If you are not the intended
>>>>>>> recipient, please contact the sender and delete the e-mail from your system
>>>>>>> without producing, distributing or retaining copies thereof.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sami Jylkkä
>>>>> Cyberlightning Ltd.
>>>>>
>>>>> www.cyberlightning.com
>>>>>
>>>>> Skype: sami_jylkka
>>>>>
>>>>> This e-mail and all attached material are confidential and may contain
>>>>> legally privileged information. If you are not the intended recipient,
>>>>> please contact the sender and delete the e-mail from your system without
>>>>> producing, distributing or retaining copies thereof.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Sami Jylkkä
>>> Cyberlightning Ltd.
>>>
>>> www.cyberlightning.com
>>>
>>> Skype: sami_jylkka
>>>
>>> This e-mail and all attached material are confidential and may contain
>>> legally privileged information. If you are not the intended recipient,
>>> please contact the sender and delete the e-mail from your system without
>>> producing, distributing or retaining copies thereof.
>>>
>>
>>
>
>
> --
> Sami Jylkkä
> Cyberlightning Ltd.
>
> www.cyberlightning.com
>
> Skype: sami_jylkka
>
> This e-mail and all attached material are confidential and may contain
> legally privileged information. If you are not the intended recipient,
> please contact the sender and delete the e-mail from your system without
> producing, distributing or retaining copies thereof.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-finodex-coaching/attachments/20150811/5d2b0349/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fiware_W3DS.png
Type: image/png
Size: 1433487 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-finodex-coaching/attachments/20150811/5d2b0349/attachment.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy