Allow lat, lon, and altitude to change about weewx HOT 11 CLOSED

we could make 'set' methods on the station object. then the location service could do a set_location(lat,lon,altitude) each time it updates the loop packet or archive record.

then just be sure that anything that uses lat/lon/alt asks for the value from the Station object instead of caching it.

as an initial implementation, we could do an abstract LocationService base class, with a concrete GPSdLocationService that gets lat, lon, altitude from gpsd. that would give weewx instant support for a wide range of gps hardware.

from weewx.

another approach would be a StaticLocationService that always returns the lat/lon/altitude that were entered in weewx.conf.

to configure weewx for a mobile station you would replace StaticLocationService with the appropriate location service, such as GPSdLocationService if you have a gpsd on the system getting coords from gpsd-supported gps hardware. or an AirMaxLocationService (defined in the airmax.py module) that returns coords from the airmax hardware.

from weewx.

or perhaps a more generic approach: the Station object would register a SetLocation service. the SetLocation service would get lat/lon/alt from each loop packet and use Station.set_location(lat,lon,alt) to set the lat/lon/alt on the station object. if there is no lat/lon/alt in the loop packet, then the service does nothing. initial values for lat/lon/alt would come from weewx.conf.

drivers for hardware with gps data (e.g., airmar) would simply add lat/lon/alt from the data they get from the hardware.

if gps data come from a separate device such as a garmin gps unit via usb/serial, then run a GPSdService that simply reads the lat/lon/alt and sticks it into each loop. this would be independent of any weather station and its driver.

from weewx.

I suppose any of these would work, but I'm leery of treating location data as special data even though, so far, we have. Why can't it be like any other data? Imagine if the wview schema had originally been designed with mobile data in mind and had columns lat, lon, and altitude. Would that solve all our problems? I'm not sure, but I think it would.

I don't want to change the schema, but we could add a separate "location" database. For non-mobile stations it would have a single entry. For mobile stations, it would be continually updated like any other database.

The problem of having multiple devices contribute to the stream of data has been solved before: create a new service that monitors a separate thread that talks to the new device. We would have a generic StdLocation service that would know how to talk to gpsd.

from weewx.

try this on for size:

option 1: the Station object starts with lat/lon/alt as specified in weewx.conf. the Station object registers itself as a service. that service watches LOOP packets for lat/lon/alt. if the packet contains them, then the service sets those values on the Station object. any other weewx components that need lat/lon/alt ask the station object for those values.

option 2: the Station object no longer contains lat/lon/alt. any other weewx components that need lat/lon/alt must get it from a LOOP packet or archive record.

(the places where stn_info is queried for lat/lon/alt are cheetahgenerator, imagegenerator, restx, and wxservices, and the extensions crt, forecast, owm, and wbug. all of these need to be modified whether we use option 1 or option 2 since they cache the values from stn_info)

1. we add a new StdLocation service that puts the lat/lon/alt values from weewx.conf into each LOOP packet.

2. we add a new GPSdLocation service to weewx that is disabled by default. this service uses gpsd to get lat/lon/alt from any attached gps hardware. if someone wants to make their station mobile, they replace StdLocation service with GPSdLocation service in weewx.conf.

3. for the airmar use case, the airmar driver would simply add lat/lon/alt to each LOOP packet.

4. lat/lon/alt data would only be saved to database if the schema includes lat/lon/alt (e.g., by extending the wview schema).

from weewx.

introduce a StdLocation service. it adds altitude, latitude, and longitude to each LOOP packet if the LOOP packet does not already have them. it gets these values from weewx.conf.

so a driver should add altitude, latitude, and longitude to each LOOP packet if it can. for example, airmar driver would add altitude, latitude, and longitude dynamically. te923 driver would read once the values for altitude, latitude, and longitude then add those to each LOOP packet. vantage driver would read altitude once then add that to each LOOP packet, StdLocation would add lat/lon from weewx.conf.

a GPSdLocation service would replace StdLocation for a site that has a non-location-aware weather station combined with a gpsd-capable gps unit. the GPSdLocation service would simply read alt/lat/lon from the hardware and stick it into each LOOP packet.

lat/lon/alt would only be saved to database if the schema were extended to include them. but they would be available in reports as current.altitude, current.latitude, current.longitude.

for backward compatibility, the Station could be a service that caches the last alt/lat/lon.

from weewx.

Sounds good.

Can we wait until V3.3 for these additions? I'd really like to get V3.2 out.

from weewx.

This is pretty essential for supporting mobile locations, but, realistically, it is unlikely to get worked on for a while. Closing for now.

from weewx.

a year has passed, do you think the time is right to address this issue? it is still essential for mobile stations. For mobile stations a dynamic converter of wind direction ( calculated from heading and sensordata ) would also be desireable. I know i ask a lot 😀

from weewx.

Both Matthew and I have thought about it, and, at least for myself, I've gotten more and more intimidated by the thought.

Another problem that we identified is time. Things like the daily highs and lows are calculated in local time. That can be very tricky to define with a mobile station.

from weewx.

well, on ships it is not unusual to deal with localtime and UTC. gpsd is a true friend and can provide localtime and UTC in addition to lat,lon,alt not only with locally connected but also with networked gps receivers. i would be happy to provide testing environment.

from weewx.