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

some semantic locations are missing placeId #57

Open
karlicoss opened this issue Nov 8, 2023 · 2 comments
Open

some semantic locations are missing placeId #57

karlicoss opened this issue Nov 8, 2023 · 2 comments

Comments

@karlicoss
Copy link
Contributor

Even in the latest export getting quite a few errors originating from

otherCandidateLocations=[
CandidateLocation.from_dict(pv)
for pv in placeVisit.get("otherCandidateLocations", [])
],

The reason is sometimes they are missing placeId which is required:

placeId=data["placeId"],

Most of them look like this, with either TYPE_HOME or TYPE_WORK:

{'latitudeE7': ..., 'longitudeE7': ..., 'semanticType': 'TYPE_HOME', 'locationConfidence': 26.890783}

(sometimes it's TYPE_HOME/TYPE_WORK and placeId is present as well, but not always)

There are a few remaining ones with different type:

{'latitudeE7': ...,
'locationConfidence': 14.805286,
'longitudeE7': ...,
'semanticType': 'TYPE_ALIASED_LOCATION'}

, however not sure what that one means.

Not sure what's the right way to handle this, perhaps making placeId optional and perhaps also adding semanticType field?

@seanbreckenridge
Copy link
Owner

Yeah... they keep changing what kinda info gets returned in location history/semantic location history

Almost want to create multiple location types and return a Union of all the different kind of semantic location models, instead of having a bunch of None's on the model and the data being very sparse. Makes it more annoying for downstream consumers to figure out what type of location data they need to process

Will do an export tonight and see if I have the same errors

Sure, You can make placeid optional and add the semantic info

@seanbreckenridge
Copy link
Owner

I think best to leave the semanticType a string, forcing an enum is prone to breaking

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

No branches or pull requests

2 participants