some semantic locations are missing placeId

[karlicoss]

Even in the latest export getting quite a few errors originating from https://github.com/seanbreckenridge/google_takeout_parser/blob/6561a6a4c89fc75766e83f624fb1a50fc4700b91/google_takeout_parser/parse_json.py#L193-L196

The reason is sometimes they are missing placeId which is required: https://github.com/seanbreckenridge/google_takeout_parser/blob/6561a6a4c89fc75766e83f624fb1a50fc4700b91/google_takeout_parser/models.py#L147

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]

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]

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