GeoJSON module

[charlieforward9]

Clear and concise description of the problem

I work with a buunch of maps, it would be suuuper helpful to have a faker module for GeoJSON related data in order to alleviate a lot of the manual mock data I have filled in the codebase.

Suggested solution

I propose that each GeoJSON type have its own mock, and common parameters be used to control things like where it shows up, how big the features can be, etc. Posting this a bit rushed to curious to see a response before diving deeper into proposal.

Alternative

No response

Additional context

No response

[github-actions]

Thank you for your feature proposal.

We marked it as "waiting for user interest" for now to gather some feedback from our community:

• If you would like to see this feature be implemented, please react to the description with an up-vote (:+1:).
• If you have a suggestion or want to point out some special cases that need to be considered, please leave a comment, so we are aware about them.

We would also like to hear about other community members' use cases for the feature to give us a better understanding of their potential implicit or explicit requirements.

We will start the implementation based on:

• the number of votes (:+1:) and comments
• the relevance for the ecosystem
• availability of alternatives and workarounds
• and the complexity of the requested feature

We do this because:

• There are plenty of languages/countries out there and we would like to ensure that every method can cover all or almost all of them.
• Every feature we add to faker has "costs" associated to it:
  • initial costs: design, implementation, reviews, documentation
  • running costs: awareness of the feature itself, more complex module structure, increased bundle size, more work during refactors

---

View more issues which are waiting for user interest

[ST-DDT]

FFR:

• https://en.m.wikipedia.org/wiki/GeoJSON
• the German (de) article has better examples IMO.

[xDivisionByZerox]

I was sceptical since the only thing i saw first was json. Historicaly, we do not return json that has dynamic content. On the other side we abrace feature which are standardized (RFC, ISO, etc). I'd say the later argument has more weigt in this scenario since we could follow RFC 7946.

Without having discussed that with the team: I'm fine with such a module in general. Would be great if other team members could reflect their opinion with a simple thumbs up ( 👍 ) or thumbs down ( 👎 ) reaction to this comment.

If my comment gets at least one upvote, could you be so kind @charlieforward9 and suggest a potential API for the implementation? This does not mean that there is a guarantee that the feature will be implemented in the near future, but it will help us evaluate the scope, technical dept and maintainance burdens of such a feature.

[ST-DDT]

I think it should have its own module as it is too much for the location module.

There are 2 things that I'm unsure about:

• does it contain localized data
• we would kind of have to duplicate the entire set of types for GeoJson types (at least 7 for Geometries + some more for features)

[matthewmayer]

I think one of the things to bear in mind you probably don't want the data to be utterly random. For example, a common use case for geoJSON might be showing a route like a GPS trace or hiking trail, or locations of restaurants in a city.

In that case you would want points fairly close together not scattered all over the globe