ropengov / fmi Goto Github PK
View Code? Open in Web Editor NEWFinnish Meteorological Institute open data API R client
License: Other
Finnish Meteorological Institute open data API R client
License: Other
This query gives the following error:
library(fmi)
# a working apiKey needs to be filled in
apiKey <- ""
request <- FMIWFSRequest$new(apiKey=apiKey)
request$setParameters(
request="getFeature",
storedquery_id="fmi::observations::weather::daily::simple",
fmisid=100971L,
starttime="2016-10-13T00:00:00",
endtime="2016-10-13T23:59:59"
)
client <- FMIWFSClient$new(request=request)
layers <- client$listLayers()
response <- client$getLayer(
layer=layers[1L],
crs="+proj=longlat +datum=WGS84",
swapAxisOrder=TRUE,
parameters=list(splitListFields=TRUE)
)
ogr2ogr -f GML -splitlistfields /var/folders/_3/gy_1s85s4dj7039m1j863x1h0000gn/T//RtmpXdfRj5/filedfcc1128407e /var/folders/_3/gy_1s85s4dj7039m1j863x1h0000gn/T//RtmpXdfRj5/filedfcc69a218fe BsWfsElement
ERROR 1: Field ParameterValue has a 4 UTF-8 characters whereas a maximum of 3 is allowed
ERROR 1: Unable to write feature 1 from layer BsWfsElement.
ERROR 1: Terminating translation prematurely after failed
translation of layer BsWfsElement (use -skipfailures to skip errors)
Error in convertOGR(sourceFile = private$cachedResponseFile, layer = layer, :
Conversion failed.
An otherwise exact same query works for most days, but fails for some, like 2016-10-13 above. Looking at the two tempfiles passed to ogr2ogr
, it seems the problem is in the first one. I wonder if this is something we can do anything about, or if the problem is on FMI's side. Here are the contents of that file:
<?xml version="1.0" encoding="utf-8" ?>
<ogr:FeatureCollection
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ogr.maptools.org/ filee4685a378a76.xsd"
xmlns:ogr="http://ogr.maptools.org/"
xmlns:gml="http://www.opengis.net/gml">
<gml:boundedBy><gml:null>missing</gml:null></gml:boundedBy>
</ogr:FeatureCollection>
And here is the corresponding file for a day that does work (2016-10-14):
<?xml version="1.0" encoding="utf-8" ?>
<ogr:FeatureCollection
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ogr.maptools.org/ filee43a5197ae0.xsd"
xmlns:ogr="http://ogr.maptools.org/"
xmlns:gml="http://www.opengis.net/gml">
<gml:boundedBy>
<gml:Box>
<gml:coord><gml:X>24.94459</gml:X><gml:Y>60.17523</gml:Y></gml:coord>
<gml:coord><gml:X>24.94459</gml:X><gml:Y>60.17523</gml:Y></gml:coord>
</gml:Box>
</gml:boundedBy>
<gml:featureMember>
<ogr:BsWfsElement fid="BsWfsElement.0">
<ogr:geometryProperty><gml:Point srsName="EPSG:4258"><gml:coordinates>24.94459,60.17523</gml:coordinates></gml:Point></ogr:geometryProperty>
<ogr:gml_id>BsWfsElement.1.1.1</ogr:gml_id>
<ogr:Time>2016-10-14T00:00:00Z</ogr:Time>
<ogr:ParameterName>rrday</ogr:ParameterName>
<ogr:ParameterValue>0.3</ogr:ParameterValue>
</ogr:BsWfsElement>
</gml:featureMember>
<gml:featureMember>
<ogr:BsWfsElement fid="BsWfsElement.1">
<ogr:geometryProperty><gml:Point srsName="EPSG:4258"><gml:coordinates>24.94459,60.17523</gml:coordinates></gml:Point></ogr:geometryProperty>
<ogr:gml_id>BsWfsElement.1.1.2</ogr:gml_id>
<ogr:Time>2016-10-14T00:00:00Z</ogr:Time>
<ogr:ParameterName>tday</ogr:ParameterName>
<ogr:ParameterValue>2.9</ogr:ParameterValue>
</ogr:BsWfsElement>
</gml:featureMember>
<gml:featureMember>
<ogr:BsWfsElement fid="BsWfsElement.2">
<ogr:geometryProperty><gml:Point srsName="EPSG:4258"><gml:coordinates>24.94459,60.17523</gml:coordinates></gml:Point></ogr:geometryProperty>
<ogr:gml_id>BsWfsElement.1.1.3</ogr:gml_id>
<ogr:Time>2016-10-14T00:00:00Z</ogr:Time>
<ogr:ParameterName>snow</ogr:ParameterName>
<ogr:ParameterValue>-1</ogr:ParameterValue>
</ogr:BsWfsElement>
</gml:featureMember>
<gml:featureMember>
<ogr:BsWfsElement fid="BsWfsElement.3">
<ogr:geometryProperty><gml:Point srsName="EPSG:4258"><gml:coordinates>24.94459,60.17523</gml:coordinates></gml:Point></ogr:geometryProperty>
<ogr:gml_id>BsWfsElement.1.1.4</ogr:gml_id>
<ogr:Time>2016-10-14T00:00:00Z</ogr:Time>
<ogr:ParameterName>tmin</ogr:ParameterName>
<ogr:ParameterValue>1.4</ogr:ParameterValue>
</ogr:BsWfsElement>
</gml:featureMember>
<gml:featureMember>
<ogr:BsWfsElement fid="BsWfsElement.4">
<ogr:geometryProperty><gml:Point srsName="EPSG:4258"><gml:coordinates>24.94459,60.17523</gml:coordinates></gml:Point></ogr:geometryProperty>
<ogr:gml_id>BsWfsElement.1.1.5</ogr:gml_id>
<ogr:Time>2016-10-14T00:00:00Z</ogr:Time>
<ogr:ParameterName>tmax</ogr:ParameterName>
<ogr:ParameterValue>3.8</ogr:ParameterValue>
</ogr:BsWfsElement>
</gml:featureMember>
</ogr:FeatureCollection>
So, looking at this, it seems like the actual data is simply missing. However, the contents of the second file that is passed to ogr2ogr
look fine. It appears completely analogous to the corresponding file for a date that works (2016-10-14), and has all the data it is supposed to have:
<?xml version="1.0" encoding="UTF-8"?>
<wfs:FeatureCollection
timeStamp="2016-12-23T10:59:58Z"
numberReturned="5"
numberMatched="5"
xmlns:wfs="http://www.opengis.net/wfs/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:BsWfs="http://xml.fmi.fi/schema/wfs/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd
http://xml.fmi.fi/schema/wfs/2.0 http://xml.fmi.fi/schema/wfs/2.0/fmi_wfs_simplefeature.xsd"
>
<wfs:member>
<BsWfs:BsWfsElement gml:id="BsWfsElement.1.1.1">
<BsWfs:Location>
<gml:Point gml:id="BsWfsElementP.1.1.1" srsDimension="2" srsName="http://www.opengis.net/def/crs/EPSG/0/4258">
<gml:pos>60.17523 24.94459 </gml:pos>
</gml:Point>
</BsWfs:Location>
<BsWfs:Time>2016-10-13T00:00:00Z</BsWfs:Time>
<BsWfs:ParameterName>rrday</BsWfs:ParameterName>
<BsWfs:ParameterValue>-1.0</BsWfs:ParameterValue>
</BsWfs:BsWfsElement>
</wfs:member>
<wfs:member>
<BsWfs:BsWfsElement gml:id="BsWfsElement.1.1.2">
<BsWfs:Location>
<gml:Point gml:id="BsWfsElementP.1.1.2" srsDimension="2" srsName="http://www.opengis.net/def/crs/EPSG/0/4258">
<gml:pos>60.17523 24.94459 </gml:pos>
</gml:Point>
</BsWfs:Location>
<BsWfs:Time>2016-10-13T00:00:00Z</BsWfs:Time>
<BsWfs:ParameterName>tday</BsWfs:ParameterName>
<BsWfs:ParameterValue>1.5</BsWfs:ParameterValue>
</BsWfs:BsWfsElement>
</wfs:member>
<wfs:member>
<BsWfs:BsWfsElement gml:id="BsWfsElement.1.1.3">
<BsWfs:Location>
<gml:Point gml:id="BsWfsElementP.1.1.3" srsDimension="2" srsName="http://www.opengis.net/def/crs/EPSG/0/4258">
<gml:pos>60.17523 24.94459 </gml:pos>
</gml:Point>
</BsWfs:Location>
<BsWfs:Time>2016-10-13T00:00:00Z</BsWfs:Time>
<BsWfs:ParameterName>snow</BsWfs:ParameterName>
<BsWfs:ParameterValue>NaN</BsWfs:ParameterValue>
</BsWfs:BsWfsElement>
</wfs:member>
<wfs:member>
<BsWfs:BsWfsElement gml:id="BsWfsElement.1.1.4">
<BsWfs:Location>
<gml:Point gml:id="BsWfsElementP.1.1.4" srsDimension="2" srsName="http://www.opengis.net/def/crs/EPSG/0/4258">
<gml:pos>60.17523 24.94459 </gml:pos>
</gml:Point>
</BsWfs:Location>
<BsWfs:Time>2016-10-13T00:00:00Z</BsWfs:Time>
<BsWfs:ParameterName>tmin</BsWfs:ParameterName>
<BsWfs:ParameterValue>0.0</BsWfs:ParameterValue>
</BsWfs:BsWfsElement>
</wfs:member>
<wfs:member>
<BsWfs:BsWfsElement gml:id="BsWfsElement.1.1.5">
<BsWfs:Location>
<gml:Point gml:id="BsWfsElementP.1.1.5" srsDimension="2" srsName="http://www.opengis.net/def/crs/EPSG/0/4258">
<gml:pos>60.17523 24.94459 </gml:pos>
</gml:Point>
</BsWfs:Location>
<BsWfs:Time>2016-10-13T00:00:00Z</BsWfs:Time>
<BsWfs:ParameterName>tmax</BsWfs:ParameterName>
<BsWfs:ParameterValue>3.4</BsWfs:ParameterValue>
</BsWfs:BsWfsElement>
</wfs:member>
</wfs:FeatureCollection>
Above I have only queried for individual days (because for another purpose I've setup a system that caches the results of daily queries). But one can also query ranges of multiple days, and then even the offending days work just fine. Out of the past 40 years, there seems to be 50 days that are problematic, when queried individually.
So, I'm not sure if this is something on our or FMI's side. And even if it is on our side, not sure if it's worth too much effort, as it can be circumvented by querying multiple days.
Following things need to be changed:
sf
-objectsI'm not sure if this is really about fmi
(or rather rwfs
), but I get the following error when I try to run the code from the tutorial:
library(fmi)
apiKey <- "" # with a valid key
request <- FMIWFSRequest$new(apiKey = apiKey)
request$setParameters(request = "getFeature",
storedquery_id = "fmi::observations::weather::daily::timevaluepair",
starttime = "2014-01-01T00:00:00Z",
endtime = "2014-01-01T00:00:00Z",
bbox = "19.09,59.3,31.59,70.13",
parameters = "rrday,snow,tday,tmin,tmax")
client <- FMIWFSClient$new(request=request)
layers <- client$listLayers()
response <- client$getLayer(layer=layers[1], parameters=list(splitListFields=TRUE))
Error in CPL_read_ogr(dsn, layer, as.character(options), quiet, type, :
Not compatible with STRSXP: [type=list].
Error in private$.getLayer(dataSource = sourceFile, layer = layer, ...) :
Fatal error.
The two files from the temp directory are attached (I added a ".txt" suffix so that GitHub would accept them).
Below is my sessionInfo()
. Both fmi
and rwfs
are the current GitHub versions (SHAs aa9ec3b and 6c341a0a).
R version 3.4.3 (2017-11-30)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS High Sierra 10.13.2
Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] fmi_0.2.1 R6_2.2.2
loaded via a namespace (and not attached):
[1] Rcpp_0.12.14 bindr_0.1 raster_2.6-7 magrittr_1.5
[5] units_0.4-6 lattice_0.20-35 rlang_0.1.6 udunits2_0.13
[9] dplyr_0.7.4 tools_3.4.3 rgdal_1.2-16 grid_3.4.3
[13] e1071_1.6-8 DBI_0.7 class_7.3-14 assertthat_0.2.0
[17] digest_0.6.13 tibble_1.4.1 sf_0.5-5 bindrcpp_0.2
[21] glue_1.2.0 sp_1.2-5 compiler_3.4.3 pillar_1.0.1
[25] rwfs_0.2.0 classInt_0.1-24 pkgconfig_2.0.1
This is with gdal 1.11.5_3
and geos 3.6.2
installed via Homebrew and rgdal
and rgeos
compiled from source. At first I had the same error message with binary versions installed from CRAN (without the Homebrew packages). But since with that setup the output from library(rgdal)
included GDAL binary built with GEOS: FALSE
and I wasn't sure if that was required, I installed the Homebrew versions and complied the R packages from source, so that it's now TRUE
:
Loading required package: sp
rgdal: version: 1.2-16, (SVN revision 701)
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 1.11.5, released 2016/07/01
Path to GDAL shared files: /usr/local/Cellar/gdal/1.11.5_3/share/gdal
GDAL binary built with GEOS: TRUE
Loaded PROJ.4 runtime: Rel. 4.9.3, 15 August 2016, [PJ_VERSION: 493]
Path to PROJ.4 shared files: /Library/Frameworks/R.framework/Versions/3.4/Resources/library/sf/proj
Linking to sp version: 1.2-5
And finally, here's ogrDrivers()$name
:
[1] "AeronavFAA" "ARCGEN" "AVCBin" "AVCE00"
[5] "BNA" "CartoDB" "CouchDB" "CSV"
[9] "DGN" "DXF" "EDIGEO" "ElasticSearch"
[13] "ESRI Shapefile" "Geoconcept" "GeoJSON" "GeoRSS"
[17] "GFT" "GML" "GMT" "GPKG"
[21] "GPSBabel" "GPSTrackMaker" "GPX" "HTF"
[25] "Idrisi" "KML" "MapInfo File" "Memory"
[29] "ODS" "OpenAir" "OpenFileGDB" "OSM"
[33] "PCIDSK" "PDF" "PDS" "PGDump"
[37] "REC" "S57" "SDTS" "SEGUKOOA"
[41] "SEGY" "SQLite" "SUA" "SVG"
[45] "SXF" "TIGER" "UK .NTF" "VFK"
[49] "VRT" "WAsP" "WFS" "XLS"
[53] "XLSX" "XPlane"
Would be useful to take this to CRAN. I can do if there are no other volunteers. But I would still direct the emails to the main developer JJ. Any comments ?
In its current form, fmi
relies on rwfs
for much of the functionality. It only implements one subclass and rest is setting up things. The generic architecture in rwfs
is useful in principle, but it is painful to develop fmi
... The class inheritance is unclear even for me and figuring what gets called and when is obscure. I've been struggling with this for years and I just don't thing the generic nature of rwfs
justifies the complexity. Especially so since rgdal
has improved a lot in terms of WFS access since rwfs
was first created and sf
is making things much easier. Much of the WFS-specific functionality that was in rwfs
is just not needed anymore. Thus, I'm thinking about doing a re-write of the whole fmi
package and retiring rwfs
completely.
Any thoughts?
As the title says. I assume the desired behaviour would be to return an empty object or something else. Or at least a more useful error message. The error seems to be in convertOGR. To which package does that belong?
> client$getDailyWeather(startDateTime="2012-05-15", endDateTime="2012-07-17", fmisid = 100929)
trying URL 'http://data.fmi.fi/fmi-apikey/the-api-key/wfs?request=getFeature&storedquery_id=fmi::observations::weather::daily::timevaluepair&starttime=2012-05-15&endtime=2012-07-17&fmisid=100929¶meters=rrday,snow,tday,tmin,tmax'
Content type 'text/xml; charset=UTF-8' length 1988 bytes
==================================================
downloaded 1988 bytes
ogr2ogr -f GML -splitlistfields /tmp/Rtmp9R6Bi7/file470e214c4ed /tmp/Rtmp9R6Bi7/file470e50047a05 PointTimeSeriesObservation
ERROR 1: Couldn't fetch requested layer 'PointTimeSeriesObservation'!
Error in convertOGR(sourceFile = private$cachedResponseFile, layer = layer, :
Conversion failed.
I will try to investigate further.
At the moment, a list of weather stations is included in inst/extdata/weather_stations.csv
. I suppose the reason for the inclusion is that these are not available through the API. I have some possible minor contributions in mind, and would like to hear the package authors' views on three points:
Right now, the list contains only stations of type "Sääasemat". This is the most common type, and can be used to retrieve information on e.g. temperature and wind. But other types of stations, such as "Poijut" (waves) and "Mareografit" (sea level) are not included.
I think it could be argued either way whether it should return all station types (for completeness) or only "Sääasemat" (for consistent behavior). One should also note that the function is called fmi_weather_stations(), not fmi_stations().
However, function valid_fmisid()
also uses this list to check for the validity of FMISIDs. For example, 134220 is the FMISID of the wave buoy of Northern Baltic Proper, but this function says that it is not a valid FMISID. This use would point towards including all stations (possibly with a new function fmi_stations()
).
The downside of including the list within the package is of course that it can get out-of-date (as it apparently has to some extent). Another option could be to include a function that scrapes it live from the FMI website, something along the lines of:
stations <- XML::readHTMLTable("http://ilmatieteenlaitos.fi/havaintoasemat",
which=1L, stringsAsFactors=FALSE) %>%
tbl_df() %>%
mutate(
FMISID=FMISID %>% as.integer(),
LPNN=LPNN %>% as.integer(),
WMO=WMO %>% as.integer(),
Lat=Lat %>% sub(pattern=",", replacement=".") %>% as.numeric(),
Lon=Lon %>% sub(pattern=",", replacement=".") %>% as.numeric(),
Korkeus=Korkeus %>% sub(pattern="\n.*$", replacement="") %>% as.integer(),
Alkaen=Alkaen %>% as.integer()
)
Downsides include the additional package dependency (XML
), and of course the fact that just like the included list can get out-of-date, this function can break at any time if FMI changes their website. Naturally, there's also the hybrid option of including one version of the list within the package and also providing a function to download it from the web.
The list can of course be in either Finnish or English. When scraping, this would apply to both column names (e.g. "Ryhmät" vs. "Groups") and contents ("Sääasemat" vs. "Weather stations"). Naturally, most (and probably practically all) use for this package is from people who have at least some level of understanding of Finnish. But sill, one could argue for keeping everything in English (like command names and documentation are).
Function get_weather_data()
used to generate the old blog post gives the following error:
kaisa.2012 <- get_weather_data(apiKey, startDateTime, endDateTime, fmisid.kaisa)
trying URL 'http://data.fmi.fi/fmi-apikey/0253711c-056f-439b-af9d-a5a3a2920faf/wfs?request=getFeature&storedquery_id=fmi::observations::weather::daily::timevaluepair&starttime=2011-12-24&endtime=2012-12-31&fmisid=100971¶meters=rrday,snow,tday,tmin,tmax'
Show Traceback
Rerun with Debug
Error in download.file(private$getURL(), destFile, "internal") :
cannot open URL 'http://data.fmi.fi/fmi-apikey/0253711c-056f-439b-af9d-a5a3a2920faf/wfs?request=getFeature&storedquery_id=fmi::observations::weather::daily::timevaluepair&starttime=2011-12-24&endtime=2012-12-31&fmisid=100971¶meters=rrday,snow,tday,tmin,tmax' In addition: Warning message:
In download.file(private$getURL(), destFile, "internal") :
cannot open URL 'http://data.fmi.fi/fmi-apikey/0253711c-056f-439b-af9d-a5a3a2920faf/wfs?request=getFeature&storedquery_id=fmi::observations::weather::daily::timevaluepair&starttime=2011-12-24&endtime=2012-12-31&fmisid=100971¶meters=rrday,snow,tday,tmin,tmax': HTTP status was '400 Bad Request'
Check what's wrong.
At least GDAL doesn't get properly installed.
See this discussion on rOpenSci forum for Best practices for testing API packages.
Requested by @SSRint
I'm trying to process the response from fmi::observations::mareograph::timevaluepair query with only one parameter (watlev).
response <- client$getLayer(layer=layers[1], parameters=list(splitListFields=TRUE))
produces a 1-feature spatialPointsDataframe, so
dat <- as.data.frame(response)
gives me a dataframe in super-wide format: one observation with all time+value pairs are variables. I find this rather difficult to clean with e.g. tidyr.
Note that this might not be an issue, rather some kind of misunderstanding from my side.
P.S. Great package BTW!
I tried to use the fmi package to get FMI weather data following an example given by @jlehtoma. However, the atached script gives an error message which I cannot interpret. However, the commands manage to open th url, and read in XML files in a temp folder, and it is possible to parse the files with the xml package (with hard work though). It would be really nice, if the package would do all that for you, and I hope that somebody could update the fmi package to work fluently.
Veli-Matti Taavitsainen
Helsinki Metropolia University of Applied Sciences
test.txt (EDIT: code pasted below by @jlehtoma)
library(dplyr)
library(devtools)
library(rwfs)
library(fmi)
stations <- fmi_weather_stations()
kiutakongas.station <- stations[99,]
apiKey <- '' #oma API-avaimeni
fmisid.kiuta <- kiutakongas.station$FMISID
request <- FMIWFSRequest$new(apiKey=apiKey)
request$setParameters(request="getFeature",
storedquery_id="fmi::observations::weather::daily::timevaluepair",
parameters="rrday,snow,tday,tmin,tmax")
client <- FMIWFSClient$new(request=request)
response <- client$getDailyWeather(startDateTime="2014-01-01T00:00:00Z",
endDateTime="2014-01-01T00:00:00Z",
fmisid=fmisid.kiuta)
request <- FMIWFSRequest$new(apiKey=apiKey)
request$setParameters(request="getFeature",
storedquery_id="fmi::observations::weather::daily::timevaluepair",
parameters="rrday,snow,tday,tmin,tmax")
client <- FMIWFSClient$new(request=request)
response <- client$getDailyWeather(variables = c("rrday", "snow", "tday", "tmin", "tmax"),
startDateTime="2014-01-01T00:00:00Z",
endDateTime="2014-01-01T00:00:00Z",
fmisid=fmisid.Kaisaniemi)
A caching mechanism is built in into e.g. rwfs::WFSCachingClient, but it doesn't seem to be working . Report an issue directly in rwfs
.
A fresh install to Ubuntu 16.04 gives
Error in `[.data.frame`(olddf, , measurementIndex[i]) :
undefined columns selected
when following the vignette for getting daily weather data with the function
client$getDailyWeather(...)
I tried to run the raster example presented in tutorial on my R-3.1.2-1.fc20.x86_64
and run into seqfault
Here is the output:
library(fmi)
Loading required package: R6
fmi - R Tools for Finnish Meteorological Institute Open Data.
Copyright (C) 2014 Jussi Jousimo et al.
https://ropengov.github.com/fmi
library(raster)
request <- FMIWFSRequest$new(apiKey=apiKey)
request$setParameters(request="getFeature",
storedquery_id="fmi::observations::weather::monthly::grid",
starttime="2012-01-01",
endtime="2012-01-01")
client <- FMIWFSClient$new(request=request)
downloaded 9041 bytes
response <- client$getRaster(parameters=list(splitListFields=TRUE))
trying URL 'http://data.fmi.fi/fmi-apikey/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/wfs?request=getFeature&storedquery_id=fmi::observations::weather::monthly::grid&starttime=2012-01-01&endtime=2012-01-01'
Content type 'text/xml; charset=UTF-8' length 9041 bytes
opened URL
ogr2ogr -f GML -splitlistfields /tmp/Rtmp2lOIWF/filecbea5e2116 /tmp/Rtmp2lOIWF/filecbe6b36a40d GridSeriesObservation
Warning 1: Field name 'validTime|TimePeriod|beginPosition' adjusted to 'validTime_TimePeriod_beginPosition' to be a valid
XML element name.
Warning 1: Field name 'validTime|TimePeriod|endPosition' adjusted to 'validTime_TimePeriod_endPosition' to be a valid
XML element name.
Warning 1: Field name 'parameter|NamedValue|value|TimeInstant|timePosition' adjusted to 'parameter_NamedValue_value_TimeInstant_timePosition' to be a valid
XML element name.
OGR data source with driver: GML
Source: "/tmp/Rtmp2lOIWF/filecbea5e2116", layer: "GridSeriesObservation"
with 1 features and 16 fields
Feature type: wkbPoint with 2 dimensions
trying URL 'http://data.fmi.fi/fmi-apikey/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/download?producer=monthly¶m=MonthlyMeanTemperature,MonthlyPrecipitation&bbox=15.9689043139365,59.6117693413028,33.0613124198255,70.0798784441389&origintime=1961-01-01T00:00:00Z&starttime=2012-01-01T00:00:00Z&endtime=2012-01-01T00:00:00Z&format=grib2&projection=epsg:4326'
Content type 'application/octet-stream' length unknown
opened URL
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..........
.......... .......... .......... .......... ..
downloaded 5.0 Mb
rgdal: version: 0.9-1, (SVN revision 518)
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 1.10.1, released 2013/08/26
Path to GDAL shared files: /usr/share/gdal
Loaded PROJ.4 runtime: Rel. 4.8.0, 6 March 2012, [PJ_VERSION: 480]
Path to PROJ.4 shared files: (autodetected)
*** caught segfault ***
address 0xd, cause 'memory not mapped'
Traceback:
1: .Call("RGDAL_OpenDataset", normalizePath(filename, mustWork = FALSE), TRUE, silent, PACKAGE = "rgdal")
2: .local(.Object, ...)
3: initialize(value, ...)
4: initialize(value, ...)
5: new("GDALReadOnlyDataset", filename, silent = silent)
6: GDAL.open(fname, silent = silent)
7: rgdal::GDALinfo(filename, silent = silent, returnRAT = RAT, returnCategoryNames = RAT)
8: doTryCatch(return(expr), name, parentenv, handler)
9: tryCatchOne(expr, names, parentenv, handlers[[1L]])
10: tryCatchList(expr, classes, parentenv, handlers)
11: tryCatch(expr, error = function(e) { call <- conditionCall(e) if (!is.null(call)) { if (identical(call[[1L]], quote(doTryCatch))) call <- sys.call(-4L) dcall <- deparse(call)[1L] prefix <- paste("Error in", dcall, ": ") LONG <- 75L msg <- conditionMessage(e) sm <- strsplit(msg, "\n")[[1L]] w <- 14L + nchar(dcall, type = "w") + nchar(sm[1L], type = "w") if (is.na(w)) w <- 14L + nchar(dcall, type = "b") + nchar(sm[1L], type = "b") if (w > LONG) prefix <- paste0(prefix, "\n ") } else prefix <- "Error : " msg <- paste0(prefix, conditionMessage(e), "\n") .Internal(seterrmessage(msg[1L])) if (!silent && identical(getOption("show.error.messages"), TRUE)) { cat(msg, file = stderr()) .Internal(printDeferredWarnings()) } invisible(structure(msg, class = "try-error", condition = e))})
12: try(rgdal::GDALinfo(filename, silent = silent, returnRAT = RAT, returnCategoryNames = RAT))
13: .rasterFromGDAL(x, band = band, objecttype, ...)
14: doTryCatch(return(expr), name, parentenv, handler)
15: tryCatchOne(expr, names, parentenv, handlers[[1L]])
16: tryCatchList(expr, classes, parentenv, handlers)
17: tryCatch(expr, error = function(e) { call <- conditionCall(e) if (!is.null(call)) { if (identical(call[[1L]], quote(doTryCatch))) call <- sys.call(-4L) dcall <- deparse(call)[1L] prefix <- paste("Error in", dcall, ": ") LONG <- 75L msg <- conditionMessage(e) sm <- strsplit(msg, "\n")[[1L]] w <- 14L + nchar(dcall, type = "w") + nchar(sm[1L], type = "w") if (is.na(w)) w <- 14L + nchar(dcall, type = "b") + nchar(sm[1L], type = "b") if (w > LONG) prefix <- paste0(prefix, "\n ") } else prefix <- "Error : " msg <- paste0(prefix, conditionMessage(e), "\n") .Internal(seterrmessage(msg[1L])) if (!silent && identical(getOption("show.error.messages"), TRUE)) { cat(msg, file = stderr()) .Internal(printDeferredWarnings()) } invisible(structure(msg, class = "try-error", condition = e))})
18: try(r <- .rasterFromGDAL(x, band = band, objecttype, ...), silent = silent)
19: .rasterObjectFromFile(x, objecttype = "RasterBrick", ...)
20: raster::brick(destFile)
21: raster::brick(destFile)
22: private$importRaster(destFile)
23: client$getRaster(parameters = list(splitListFields = TRUE))
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection:
Previously this apparently was not possible, hence downloading the data and using ogr2ogr
locally. Doing so seems to be very error prone, see if rgdal
can do this using a newer version of GDAL
(e.g. >= 2.1.0 1.11, rgdal
2.0.0 is still in beta).
Clean up the old vignette to reflect the (package) API changes in 0.2.0. Also include the lightnings data example.
Currently fmi
's architecture (as well as rwfs
's) is very object-oriented (OO). Implementation is done using R's R6
object system. While this does bring all the benefits of OO in the code architecture (inheritance, encapsulation etc), it does produce a rather un-idiomatic interface to users. Consider creating and using the FMIWFSClient
:
library(fmi)
request <- fmi:: FMIWFSRequest$new(apiKey=apiKey)
request$setParameters(request="getFeature",
storedquery_id="fmi::observations::weather::daily::timevaluepair",
starttime="2014-01-01T00:00:00Z",
endtime="2014-01-01T00:00:00Z",
bbox="19.09,59.3,31.59,70.13",
parameters="rrday,snow,tday,tmin,tmax")
client <- fmi::FMIWFSClient$new(request=request)
layers <- client$listLayers()
response <- client$getLayer(layer=layers[1], parameters=list(splitListFields=TRUE))
For anyone coming from proper OO languages, this (object methods access) is intuitive. For anyone only accustomed to R, this may be confusing. More idiomatic (i.e. functional programming) API would look something like this:
library(fmi)
request <- fmi::wfs_request(apiKey = apiKey)
request <- fmi::set_parameters(request = "getFeature",
storedquery_id = "fmi::observations::weather::daily::timevaluepair",
starttime = "2014-01-01T00:00:00Z",
endtime = "2014-01-01T00:00:00Z",
bbox = "19.09,59.3,31.59,70.13",
parameters = "rrday,snow,tday,tmin,tmax")
client <- fmi::wfs_client(request = request)
layers <- fmi::list_layers(client)
respones <- fmi::get_layer(layer = layers[1], parameters = list(splitListFields = TRUE))
Not a high priority IMHO since the current implementation works, but worth considering. The latter API could be implemented on top of the current architecture without the need to re-write everything.
Opinions? @torsti @antagomir @muuankarski
I'm still new to proper R packaging and not entirely familiar with the build process, but could we automate the Roxygen2 step and remove generated content from the repository?
Check that new contributors are properly acknowledged in DESCRIPTION and CITATION
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.