Hi Sami,
I have been working on the XML3D objects and it seems that I was able to
introduce the objects in the test scenario as you can see on the attached.
We have to solve some problems with shadows/light on the objects but I
expect to be quite easy to solve it.
I saw on wednesday that you uploaded a new GIS client version (4.4.2). I
was yesterday testing it and it seems that everything is going well. Now, I
am trying to merge the xml3d and DEM examples to be able to introduce the
XML3D objects on our terrain/texture. I will show you when I advance on
this.
Just on comment about the 4.4.2 version (and also previous versions). I
found a little error/bug on your JS script on xml3d example (path:
GIS_Client_xml3d/scripts/scenemngr.js) line 222 where X and Y are mixed as
seen below:
if (LayerMaxY < parseFloat(higherCornerSplit[1]) || LayerMaxX
===null){ -> Wrong
if (LayerMaxY < parseFloat(higherCornerSplit[1]) || LayerMaxY
===null){ -> Correct
Best regards,
Ibon
2015-08-19 6:49 GMT+00:00 Sami J <sami.jylkka at cyberlightning.com>:
> Hi Ibon,
> I have updated *GIS_Client_xml3d*-client and it now supports adding
> external XML3D models on top of the terrain. You can try the functionality
> by getting latest changes from the github and using
> *DEM_geotiff_terrain_EPSG3067.tiff* as a elevation source and
> *fiware:building_coordinates* for querying also building models*. *Reference
> client works so that *addMeshtoHtml()* -function in *scenemngr.js*
> creates external model definitions and adds them to the DOM. URL to the
> model definition file is received from the server, so if you would like to
> try eg suzanne.json instead of xml-url received from the server, you can
> just replace xml URLwith URL to json file. in example like this:
> *var meshString = "<mesh src=\"../3Dmodels/suzanne.json\"/>";*
>
> For further details related to XML3D I recommend http://xml3d.org/, there
> is a lot of details how to use XML3D in the web page and how to manipulate
> objects. Also good examples can be found from there.
>
> Best regards,
> Sami
>
> On Tue, Aug 18, 2015 at 4:27 PM, Ibon Salbidegoitia <ibon.salbi at gmail.com>
> wrote:
>
>> Hi Sami,
>>
>> I still continue making some modifications to show the maps, but I write
>> this email for a question related to XML3D objects I asked you last week.
>> The client example focuses on a postGIS data to create the XML3D objects
>> (the buildings). I have the objects in a JSON format as the one attached
>> (or here
>> <http://xml3d.github.io/xml3d-examples/examples/suzanne/suzanne.json>)
>> for this example:
>> http://xml3d.github.io/xml3d-examples/examples/suzanne/suzanne.html
>> To create complex and time-changable 3D images is a very suitable format,
>> so I would like to know how can this XML3D objects can be introduced in a
>> JSON format inside the scene.
>> Thank you in advance. Best regards,
>>
>> Ibon
>>
>>
>> 2015-08-11 7:12 GMT+00:00 Ibon Salbidegoitia <ibon.salbi at gmail.com>:
>>
>>> 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.
>>>>
>>>
>>>
>>
>
>
> --
> 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/20150828/9ae4b92b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XML3D_test1.png
Type: image/png
Size: 1518255 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-finodex-coaching/attachments/20150828/9ae4b92b/attachment.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy