Gazetteer entries are out of sync in ARIES shell

[lambdatronic]

The gazetteer system has seen numerous iterations, and over time they have fallen out of sync with one another. This should be remedied prior to a stable release of ARIES.

The locate command provides this list of locations to choose from:

> locate
        raven_ridge
        chehalis_original
        europe_bbox
        lye_brook
        aries-coverage-water
        vt
        vtcoverage
        usa_bbox
        san_pedro_us
        la_antigua_corrected
        san_pedro_sprnca
        DR
        aries-coverage-fisheries
        mg
        aries-coverage-coastalprotection
        viewshed
        aries-coverage-valuation
        mg_coastal
        mg_sed
        san_pedro
        ca_mark_watershed
        DRsm
        aries-coverage-sediment
        la_antigua
        aries-coverage-carbon
        raven_ridge_large
        agri
        chehalis
        aries-coverage-aesthetics
        ca_mark
        aries-coverage-flood

Running locate for any location in this list, correctly returns its polygon in WKT format:

> locate mg
0.      mg      1%      mg
        POLYGON ((41.352539056744014 -27.644606378394307, 52.778320305152796 -27.644606378394307, 52.778320305152796 -10.488, 41.352539056744014 -10.488, 41.352539056744014 -27.644606378394307))

However, attempting to use this command on any of the contexts defined in core.contexts.beta, leads to failure:

> locate core.contexts.beta/san_pedro_us512
no results found

Similarly, the coverage command's --area option only accepts locations from the locate-printable list:

> coverage core.models.water-san-pedro/surface-diversions
POLYGON ((-110.255 31.803, -110.205 31.803, -110.205 31.923, -110.255 31.923, -110.255 31.803))

> coverage -c san_pedro core.models.water-san-pedro/surface-diversions
POLYGON ((-110.255 31.803, -110.205 31.803, -110.205 31.923, -110.255 31.923, -110.255 31.803))

> coverage -c core.contexts.beta/san_pedro_us512 core.models.water-san-pedro/surface-diversions
org.integratedmodelling.thinklab.exception.ThinklabResourceNotFoundException: resource not found: no shape found for core.contexts.beta/san_pedro_us512
        at org.integratedmodelling.modelling.commands.CoverageCommand.execute(CoverageCommand.java:83)
        at org.integratedmodelling.thinklab.command.CommandManager.submitCommand(CommandManager.java:120)
        at org.integratedmodelling.thinklab.commandline.Shell.startConsole(Shell.java:114)
        at org.integratedmodelling.thinklab.shell.ShellApplication.startApplication(ShellApplication.java:126)
        at org.java.plugin.boot.Boot.boot(Boot.java:346)
        at org.java.plugin.boot.Boot.main(Boot.java:243)
 error: resource not found: no shape found for core.contexts.beta/san_pedro_us512

This is unintuitive because the observe, model, and storyline commands now expect contexts defined in core.contexts.beta and disregard those printed by locate.

> observe waterSupplyService:SurfaceDiversionCapacity core.contexts.beta/san_pedro_us512
 --- Observation 0 ----------------

(measurement:Measurement#Diversions2
  (rdfs:label Diversions2)
  (rdfs:comment 'Data source: Digitized locations of St. David and Pomerene diversions')
  (measurement:unit
    (thinklab-core:Text mm))
  (observation:hasDataSource
    (geospace:WCSDataSource#urn:uuid:ins:58524522-1d23-438b-ab01-d8d2f5dcd824
      (rdfs:label urn:uuid:ins:58524522-1d23-438b-ab01-d8d2f5dcd824)
      (geospace:hasCoverageId
        (thinklab-core:Text sanPedro:Diversions2))
      (geospace:hasNodataValue
        (thinklab-core:Number -3.4028234663852886E38))
      (geospace:hasServiceUrl
        (thinklab-core:Text http://ecoinformatics.uvm.edu/geoserver/wcs))))
  (observation:hasObservable
    (waterSupplyService:SurfaceDiversionCapacity#urn:uuid:ins:0db37637-24df-4843-a586-86a2107ef6f8
      (rdfs:label urn:uuid:ins:0db37637-24df-4843-a586-86a2107ef6f8)))
  (observation:hasObservationExtent
    (geospace:RasterGrid#urn:uuid:ins:0d95b510-0d7a-46f5-b689-47d4c73fd072
      (rdfs:label urn:uuid:ins:0d95b510-0d7a-46f5-b689-47d4c73fd072)
      (observation:hasObservable
        (geospace:SubdividedSpace#null_317
          (rdfs:label null_317)))
      (geospace:hasCoordinateReferenceSystem
        (thinklab-core:Text EPSG:4326))
      (geospace:hasYRangeMax
        (thinklab-core:Number 10.0))
      (geospace:hasLonLowerBound
        (thinklab-core:Number -110.255))
      (geospace:hasXRangeMax
        (thinklab-core:Number 3.0))
      (geospace:hasLatLowerBound
        (thinklab-core:Number 31.803))
      (geospace:hasLatUpperBound
        (thinklab-core:Number 31.923))
      (geospace:hasLonUpperBound
        (thinklab-core:Number -110.205))))
  (metadata:hasPriority
    (thinklab-core:Number 0.0)))

> observe waterSupplyService:SurfaceDiversionCapacity san_pedro
org.integratedmodelling.thinklab.exception.ThinklabResourceNotFoundException: resource not found: no context found for san_pedro
        at org.integratedmodelling.modelling.model.ModelFactory.requireContext(ModelFactory.java:316)
        at org.integratedmodelling.modelling.commands.ObserveCommand.execute(ObserveCommand.java:65)
        at org.integratedmodelling.thinklab.command.CommandManager.submitCommand(CommandManager.java:120)
        at org.integratedmodelling.thinklab.commandline.Shell.startConsole(Shell.java:114)
        at org.integratedmodelling.thinklab.shell.ShellApplication.startApplication(ShellApplication.java:126)
        at org.java.plugin.boot.Boot.boot(Boot.java:346)
        at org.java.plugin.boot.Boot.main(Boot.java:243)
 error: resource not found: no context found for san_pedro

> model -d core.models.water-san-pedro/surface-diversions san_pedro
org.integratedmodelling.thinklab.exception.ThinklabResourceNotFoundException: resource not found: no context found for san_pedro
        at org.integratedmodelling.modelling.model.ModelFactory.requireContext(ModelFactory.java:316)
        at org.integratedmodelling.modelling.commands.ModelCommand.execute(ModelCommand.java:151)
        at org.integratedmodelling.thinklab.command.CommandManager.submitCommand(CommandManager.java:120)
        at org.integratedmodelling.thinklab.commandline.Shell.startConsole(Shell.java:114)
        at org.integratedmodelling.thinklab.shell.ShellApplication.startApplication(ShellApplication.java:126)
        at org.java.plugin.boot.Boot.boot(Boot.java:346)
        at org.java.plugin.boot.Boot.main(Boot.java:243)
 error: resource not found: no context found for san_pedro

It seems desirable that all available locations/contexts should be centrally available via the locate command, and that all commands using location/context information should work with those defined both via defcontext statements and via the external gazetteer file mechanism.

Additionally, the gazetteer command should also be linked into this to also make its imported layers available via locate, observe, coverage, model, and storyline.

[fvilla]

this issue results from a complete misunderstanding of what a context is vs. a gazetteer location. The way to use locations in contexts has been documented before (in emails only I'm afraid). I'll write a doc page on contexts on the wiki when I can, although at this point just a look at a defcontext should suggest what the difference is. The fact that you can do 'list locations' and 'list contexts' with different outputs should also suggest that they're not out of sync, just different things that must not be in sync.

Closing the issue as nothing in it makes any sense.

[lambdatronic]

Closing the issue as nothing in it makes any sense.

Now that is just rude.

My description of the issue was extremely clear with lots of examples. If locations and contexts are different things, perhaps you could simply state that and give a documented explanation of how we can use locations in our modelling (as currently neither Ken, Brian, nor I have any clue as to how to do this). Furthermore, perhaps you could describe a mechanism to extract locations from contexts so we could use some of these commands (e.g. locate and coverage) to aid in our model debugging.

Sheesh.