Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend DescribeFeatureType methods to support multiple typeNames #65

Open
maelle opened this issue Mar 11, 2022 · 9 comments
Open

Extend DescribeFeatureType methods to support multiple typeNames #65

maelle opened this issue Mar 11, 2022 · 9 comments

Comments

@maelle
Copy link

maelle commented Mar 11, 2022

The context is that I'm wondering how we could get more info on what we're going to get before using getFeatures() itself.

Thanks in advance!

@maelle
Copy link
Author

maelle commented Mar 11, 2022

I think I misread what the element vs complexType are, however I'm still wondering whether the metadata could help one see what's geographical (sf) vs not (data.frame).

@eblondel
Copy link
Owner

DescribeFeatureType should target 0..* cardinality for typeNames , as part of the WFS spec, so in principle we should be able to implement it. Possibly the same for GetFeatures, but i can't work on it immediatly. In general DescribeFeatureType and GetFeature are not used on more than one typeNames, although it is possible in the standard model.

You can get information of feature type before doing Get Feature, you do it when finding/accessing a feature type where a DescribeFeatureType operation is done when triggering getDescription() method.

For example

wfs <- WFSClient$new("https://www.fao.org/fishery/geoserver/wfs", "2.0.0", logger = "INFO")
fao_areas <- wfs$capabilities$findFeatureTypeByName("fifao:FAO_MAJOR")
fao_areas_desc <- fao_areas$getDescription(pretty = T)

@eblondel eblondel changed the title Two questions on DescribeFeatureType Extend DescribeFeatureType methods to support multiple typeNames Mar 11, 2022
@maelle
Copy link
Author

maelle commented Mar 11, 2022

Thank you!

Oh right and if none of the types is "geometry" then one can conclude it'll be a data.frame, correct?

@eblondel
Copy link
Owner

Yes ows4R behaves like that. You can publish (in particular in Geoserver) geometryless data through WFS protocol, ows4R will retrieve a data.frame instead of a sf object.

@eblondel
Copy link
Owner

You can still filter over the properties you want to be part of the output with the WFS propertyName parameter. See below an exampe where I skip the geometry:

fao_areas_data = fao_areas$getFeatures(propertyName = "F_CODE,F_LEVEL")

@maelle
Copy link
Author

maelle commented Mar 11, 2022

Thanks!

Is this "type guessing before download" something that should happen in ows4R (like getTitle() there could be getRType() or so) or in EMODnetWFS?

@eblondel
Copy link
Owner

eblondel commented Mar 11, 2022

The type is the R type already. The guessing is done in https://github.com/eblondel/ows4R/blob/master/R/WFSFeatureTypeElement.R#L119. For backward compatibility reasons, I can't really change the method now so getType will give the R type, but if you need the WFS type, I can add a method getNativeType or something similar

fao_areas_desc <- fao_areas$getDescription(pretty = F)
will give you the raw list of WFSFeatureTypeElement from which you can apply the getType. The above with pretty = T is just a convenience to get tabular view over the feature type definition

@eblondel eblondel self-assigned this Mar 11, 2022
@maelle
Copy link
Author

maelle commented Mar 11, 2022

I think by type I meant layer type actually. I.e. knowing in advance when we do getFeatures(), if the resulting thing will be a data.frame or a sf. Sorry for getting this mixed up.

@maelle
Copy link
Author

maelle commented Mar 11, 2022

Example:

library("EMODnetWFS")
wfs <- emodnet_init_wfs_client(
    service = "biology_occurrence_data"
)
#> Loading ISO 19139 XML schemas...
#> Loading ISO 19115 codelists...
#> Loading IANA mime types...
#> No encoding supplied: defaulting to UTF-8.
#> ✓ WFS client created succesfully
#> ℹ Service: 'http://geo.vliz.be/geoserver/Dataportal/wfs'
#> ℹ Version: '2.0.0'

layers <- emodnet_get_wfs_info(wfs)[["layer_name"]]

is_geom <- function(layer_name, wfs) {
    layer <- wfs$capabilities$findFeatureTypeByName(sprintf("Dataportal:%s", layer_name)) 
    geom <- any(layer$getDescription(pretty = T)$type == "geometry")
    tibble::tibble(
        layer = layer_name,
        geom = geom
    )
} 

layers_info <- purrr::map_df(layers, is_geom, wfs = wfs)
knitr::kable(layers_info)
layer geom
abiotic_observations TRUE
biotic_observations TRUE
eurobis-obisenv_basic FALSE
eurobis-obisenv_count FALSE
eurobis-obisenv_full TRUE
eurobis-obisenv TRUE
eurobis_grid_15m-obisenv TRUE
eurobis_grid_1d-obisenv TRUE
eurobis_grid_30m-obisenv TRUE
eurobis_grid_6m-obisenv TRUE
eurobis_points-obisenv TRUE
iucn_grid TRUE
abiotic_observations_count FALSE
biotic_observations_count FALSE
categories FALSE
categories_get_by_datatype FALSE
datafiches_get_by_datasource_and_dataorigin_and_datatype FALSE
dataorigin_get_by_datasource_and_datatype FALSE
dataportal_get_observations_where TRUE
dataproviders_get_by_datatype FALSE
datasets FALSE
eurobis TRUE
geoobjects TRUE
geoobjects_get_by_name FALSE
parameters FALSE
parameters_get_by_name_and_category FALSE
taxa FALSE

Created on 2022-03-11 by the reprex package (v2.0.1)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants