Customizing the map style with cloud-based maps styling

[nelsonprsousa]

Feature request

Currently it's possible to customize Google Maps based on a JSON generated with the old style wizard from Google. However, seems that Google is deprecating the client-side way and is preferring the cloud-based styling: https://cloud.google.com/blog/products/maps-platform/introducing-new-maps-customization-features

Why it is needed

Google introduced new Maps customization features here: https://cloud.google.com/blog/products/maps-platform/introducing-new-maps-customization-features

The new styling website is already up here: https://mapstyle.withgoogle.com/

Possible implementation

I believe the Android and iOS SDKs receive a new prop with the map id, but I am not sure. Maybe we can map it and cross it to the native side.

Android implementation: https://developers.google.com/maps/documentation/android-sdk/cloud-based-map-styling#add-map-id

iOS implementation: https://developers.google.com/maps/documentation/ios-sdk/cloud-based-map-styling#add-a-map

Code sample

<MapView
      region={this.state.region}
      onRegionChange={this.onRegionChange}
      customMapStyleId={"2416e751bcfc2010"} // Map Id from Google Maps Platform
/>

[JordanBlazevich]

Hey @nelsonprsousa,

We are just implementing this package, and I was creating a style for the team using the old JSON style editor. It does not give me the zoom-level control that I was looking for. Are we currently unable to use the new cloud styles until this feature is implemented?

EDIT: If so, +1 to this feature request

[nelsonprsousa]

Hey @nelsonprsousa,

We are just implementing this package, and I was creating a style for the team using the old JSON style editor. It does not give me the zoom-level control that I was looking for. Are we currently unable to use the new cloud styles until this feature is implemented?

EDIT: If so, +1 to this feature request

Hi @JordanBlazevich,

As far as I know, yes, this package isn't yet compatible with the new cloud styles, hence the feature request.

[salah-ghanim]

@nelsonprsousa this seems like a straightforward feature, we might need to update the google map SDK to support it in case the current SDK doesn't but the rest is just passing down the prop to the native views, can you try and do a pull request for this feature?

[margabit]

Are there any plans to implement this feature?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nelsonprsousa]

Can we re open this issue?
cc @salah-ghanim @christopherdro

[stazrad]

ok check this out- I found a jsfiddle that uses the google maps js sdk which makes a batch request for map_ids under the hood:

https://maps.googleapis.com/maps/api/mapsjs/mapConfigs:batchGet?map_ids=8e0a97af9386fef&language=en-US&region=US&alt=protojson&major_version=46&minor_version=8

This could be implemented in react-native-maps with the customMapStyle prop as a workaround to fetch styles 🚀

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ryansalatti]

ok check this out- I found a jsfiddle that uses the google maps js sdk which makes a batch request for map_ids under the hood:

https://maps.googleapis.com/maps/api/mapsjs/mapConfigs:batchGet?map_ids=8e0a97af9386fef&language=en-US&region=US&alt=protojson&major_version=46&minor_version=8

This could be implemented in react-native-maps with the customMapStyle prop as a workaround to fetch styles 🚀

Hey I noticed your jsfiddle link is broken. Could you reshare? Really looking for a workaround on this.

[sierrakn]

I think this should be reopened

[monholm]

I'm happy to reopen this, but since no one has mentioned it yet, I need to make sure that everyone who is requesting this is aware that it's a paid feature? See Android pricing & iOS pricing.

I'm quite hesitant to implemet paid features in react-native-maps, but if there's enough demand for it, I will of course reconsider.

[nelsonprsousa]

I'm happy to reopen this, but since no one has mentioned it yet, I need to make sure that everyone who is requesting this is aware that it's a paid feature? See Android pricing & iOS pricing.

I'm quite hesitant to implemet paid features in react-native-maps, but if there's enough demand for it, I will of course reconsider.

I am the OP who opened the issue (now discussion). At the time it wasn't a paid feature, and I already moved from this solution, but lets see current demand from others.

[sierrakn]

We are unable to display skyscrapers using the footprint styling which is quite annoying without cloud based styling. So it would be useful to us.

[go-sean-go]

Just to summarize my post from #4361 (and throw in a vote for this enhancement): Google has deprecated the "old way", so regardless of our feelings about paying...eventually, it's coming (though I imagine there's some free tier on this stuff?). That the existing JSON method is deprecated makes this an imperative future-facing add (imo!).

To be clear, I don't think we should remove JSON support on the client - this could probably be well-served by a new param/prop, a la MapView.customMapStyleId or similar (leaving MapView.customMapStyle in-place as-is). And, as stated above, the props all exist on the first-party iOS & Android SDKs, so hopefully this is not a super-heavy load on react-native-maps.

The react-native-maps Readme points to the Google page that explains the deprecation, here: https://mapstyle.withgoogle.com/

More info from Google on why this is important (2-year-old blog post): https://cloud.google.com/blog/products/maps-platform/introducing-new-maps-customization-features

[localjo]

This library really should support using all features of the Google Maps SDK whether Google charges for usage of those features or not. Otherwise, it's limiting the ability to use Google Maps in our projects. It appears that the map ID is Google's preferred way to styling map layers going forward making this a pretty key feature. Supporting this from the library seems to me a matter of passing the map ID through to the SDK. The payment side of things doesn't require any special implementation on this end. We're in the process of evaluating whether we can use react-native-maps for our Google Maps based app, and without support for this feature the library is really incomplete for us and wouldn't enable us to make use of all the available Google Maps features we require.

[saransh-malik]

We would require this too, it seems a pretty useful feature and is going to be the standard going forward.

[kneza23]

Any news on this? 2 years have passed, still no conclusion?

[bhomaramgtsinfo]

Hey guys any response for map ID

[sabuhiteymurov]

Are there any updates on this issue? Adding this support would be an extremely valuable feature for developers like myself, who require flexibility and customization in map applications. I understand that this is a paid feature, but there is so much demand for it. I am eagerly waiting for this feature to be added. I appreciate all of your hard work.

[fabiuccio]

Same here. I really need this. That's pretty much the standard with Google Maps now, can you please update this thread?

[JKKholmatov]

Any updates?

[sercaneryaz]

any updates?

[onurusluca]

We really need this

[Scoutzknifez]

Need this still...

[salah-ghanim]

My question to everyone commenting here, did anyone try to create a PoC / Proof of Concept implementation here to see what's the best way to go about this ? as @monholm mentioned it doesn't feel high prio to implement paid features in an open source project.

especially when patch-package exist which should allow you to add your customisations on top of react-native-maps without being stuck in an old version.

[go-sean-go]

I believe the goal of this package is to provide a cross-platform interface to the Apple Maps and Google Maps SDKs. Is that right? If so, I believe it should not be opinionated about whether users want to or are willing to pay for the features the underlying package expose.

We don't want to remove the legacy JSON implementation; we just want a cross-platform interface to all of the features of the Apple Maps and Google Maps SDKs.

In terms of level of effort, on the iOS SDK at least, my understanding of this feature is that it's just a new property on the underlying SDK's interface, and so I imagine the react-native-maps implementation would merely be to expose that new property - and that's it.

Ultimately, @monholm said he would consider adding this if 'there's enough demand for it'. Well, it's the number 1 most requested feature in this Discussion board with ~2x as many votes as second place. Is that enough? I don't know - that's up to the maintainers. But we can at least say there's no other new feature the community wants more than this. If I'm correct that the effort is low (and I may be wrong!), this feels like a huge effort-to-value unlock for the community.

Just my two cents - I'm just a commenter, so do with it what you will.

[1kDustin]

We are currently evaluating the transition to React Native Maps from Mapbox, with a particular emphasis on the pivotal criterion of cloud-based styling support. Can we get any insights into the likelihood of the implementation of this feature?

[salah-ghanim]

Just in time for Christmas ;)

I just managed to create a pull request, that implements this feature, happy testing !

#4922 (comment)

the googleMapId can be passed as a prop to the mapView

support for iOS is blocked due to this issue on google's side:
googlemaps/google-maps-ios-utils#451

[go-sean-go]

FYI: I received the following notice from Google earlier this morning (which is not surprising and was forecasted by their earlier comms):

Hello Google Maps Platform Customer,

We are writing to let you know that all legacy map styles will need to migrate to the next-generation of cloud-based maps styling to bring more customization capabilities for developers.

All Google cloud projects with existing legacy map styles or those who have chosen to opt-out of the next-generation of cloud-based map styling prior to March 18, 2024, will be able to retain those preferences until March 18, 2025.

Below are some key dates you need to take note of:

Starting March 18, 2024, you will not be able to create new legacy map styles unless you have previously opted-out of the latest version of cloud-based map styling. However, any previously-created legacy map styles will still be available during the migration period.

After March 18, 2025, all legacy map styles will be automatically migrated and decommissioned. Please note that this automatic migration might result in some changes to the map styles.

What do you need to do?
Update any legacy map styles to the latest version before March 18, 2025 to avoid any disruption in some of your map styles.

...

Again, per comments above, this change is coming and is non-optional.