Skip to main content

2 posts tagged with "geocoding"

View All Tags

Trek's File Storage System with Amazon S3

· 4 min read
Jacob Zhu
Developer
Matthew Kang
Developer
note

This blogpost is a modified version of an internal Trek document. You can view the internal document here.

At Trek, our goal is to make trip planning as smooth and efficient as possible. To achieve this, we decided to integrate AWS S3 for storing images and files, allowing users to upload photos and other media easily. In this blog post, we’ll walk you through our integration process, the challenges we faced, and how we overcame them.

Why AWS S3?

AWS S3 (Simple Storage Service) provides scalable object storage, making it an ideal choice for our needs. It offers:

  • Reliable and durable storage.
  • Scalability to handle large amounts of data.
  • Integration with other AWS services.
  • Secure access control and management.
  • Overview of the Integration

The integration of AWS S3 in Trek is handled entirely by our backend Express server to ensure security and simplicity. Here’s a high-level overview of the data flow when a user uploads an image:

  • User Uploads Image: The user uploads an image through the frontend.
  • Backend Processing: The image is sent to the backend server, which handles the upload to S3.
  • S3 Storage: The image is stored in an S3 bucket.
  • MongoDB Logging: Metadata about the uploaded image is logged in our MongoDB database.
  • S3 Pricing Considerations

While AWS offers a Free Tier with the following limits:

  • 5GB of S3 storage.
  • 20,000 GET requests.
  • 2,000 PUT, COPY, POST, or LIST requests.
  • 100GB of data transfer out per month.

It’s essential to monitor usage to avoid unexpected costs. We learned the hard way when a private, empty S3 bucket unexpectedly incurred a $1300 charge. Always monitor your S3 usage and set budget alerts to avoid surprises.

Setting Up AWS Access

To interact with AWS S3, we use an IAM user, trek-s3-user, which has the necessary permissions to upload files. The credentials are stored in environment variables for security:

ATLAS_URI="..."
AWS_ACCESS_KEY_ID=your_access_key_id
AWS_SECRET_ACCESS_KEY=your_secret_access_key
AWS_REGION=us-east-2
S3_BUCKET_NAME=cpsc-455-trek

These keys are used by our backend server to authenticate requests to AWS S3.

MongoDB Schema for S3 Files

We keep track of the files stored in S3 using a MongoDB collection called S3Files. Here’s the schema:

  • _id: Auto-generated unique ID.
  • key: S3 object key.
  • bucket: S3 bucket name.
  • url: URL of the stored object.
  • upload_by: User ID of the uploader.
  • upload_time: Timestamp of the upload.

Backend Validation Before Upload

To ensure that only appropriate files are uploaded, we perform several validations on the backend:

  • File Type: Verify the file type being uploaded.
  • File Size: Check if the file size is within acceptable limits.
  • Upload Frequency: Limit the number of files a user can upload within a specific period.

Middleware for S3 & MongoDB

Our backend uses Express middlewares to handle the upload and logging process:

  • Auth0 Middleware: Verifies the JWT token and appends user information to the request.
  • S3 Middleware: Uploads the image to S3 and appends the metadata to the request.

Here’s an example of the S3 uploading middleware:

import { upload } from './s3/upload';

app.post('/test/upload', upload.array('photos', 3), function (err, req, res) {
if (err) {
// handle upload error
}
res.send('Successfully uploaded ' + (req.files?.length ?? 0) + ' files!');
});

If an error occurs during the upload, it’s passed to the callback function, allowing for proper error handling.

Conclusion

Integrating AWS S3 into Trek has enhanced our ability to handle user-uploaded images efficiently and securely. By leveraging AWS S3’s scalable storage and integrating it with our backend, we’ve ensured that our users have a seamless experience when planning their trips. We hope our journey and insights help you in your own integration projects.

Stay tuned for more updates and technical deep dives from the Trekkers team!

Choosing the Best Geographic Information System (GIS) for Trek

· 5 min read
Matthew Kang
Developer
note

This blogpost is a modified version of an internal Trek document. You can view the internal document here.

Integrating Google Maps was our original plan at Trek until we realized that the cost of integrating Google Maps would be outside our budget, as well as the budget of anyone deploying Trek.

Although Google provides its customers with a $200 credit for the use of their APIs, including the Google Maps Platform APIs, once customers exceed the $200 limit, they are faced with potentially thousands of dollars in billing statements.

The truth is, Google holds a monopoly over high-quality geographical information, especially their Places API, which provides the best up-to-date Points of Interest (POI) data. Using Google would be the best move if we could afford to lose the money. Unfortunately, we are not one of those companies that can lose money for a decade before making a profit.

Furthermore, Google does not allow its customers to cache or store any of its data (with the exception of place IDs), which means that every time we want to display a place name for the user, we have to call Google's API—something we cannot afford.

This blog post goes through the GIS alternatives to Google Maps that we have explored in the process of designing and building Trek.

What is a GIS?

A Geographic Information System (GIS) is a powerful tool that allows users to visualize, analyze, and interpret spatial and geographic data. In the context of Trek, a GIS is essential for enhancing the user experience by providing detailed and interactive maps, route planning, and information on places of interest. It integrates various data sources to create a comprehensive view of the trip and the world.

A Geographic Information System (GIS) for Trek should offer the following features or services:

Maps - Various visual dynamic maps imagery. Displays maps for ‘Map View’ and location markers, ‘Pins’ within the map, and geographic information (longitude and latitude) to provide context when searching for places.

Routes - Provides routing information in ‘driving’, ‘transiting’, ‘cycling’, or ‘walking’. Find best routes from place to place in different transportation methods.

Places of Interest (POI) - Provides information on places and ability to search for places. Gathers and provides place information including place ID (identifiers), name, location, description, address, photo, and reviews.

What makes a GIS Good (for Trek)?

GIS can be used in many different applications and use cases. The goal of GIS in Trek is to help meet its functional and non-functional requirements, including scalability and future-oriented design. The goal is to explore different GIS options Trek can integrate, while considering the following:

Compliance — “Are we complying with GIS’ Terms of Service? Are we stealing data and potentially committing academic misconduct?”

UI/UX — “Does the UI Look Good?”

Usability — “Does it provide good usability with sufficient information of places and provide quality search and personalization?”

Sustainability — “Will the system be financially sustainable with the integration costs? Can costs be lowered by caching or storing data?”

Maintainability — “Is the information easily manageable and does not require frequent extensive maintenance on Trek’s end?”

Dependency — “Can we manage our own information without relying on the GIS? Are we able to migrate from this GIS to another system easily”

Comparison of GIS API Integrations

Some GIS services do not provide all three packages (Maps, Routing, POI). Some GIS services do not allow caching or storage of data. Some GIS services are outside our budget.

Summary

APIMaps & RoutingPlaces of InterestsCaching & StoringPricingDescription
Google Maps PlatformBestPhotos, ReviewsRestrictiveHighBest up-to-date POI information
FourSquareN/A (POI only)Photos, ReviewsRestrictiveMediumProvides decent POI and places ‘personalization’; best for tourist POI
MapboxGoodIntegrates FourSquareRestrictive (non-enterprise)Medium/LowAlternative to Google Maps. Good UI. OSM-based. Second most popular
LocationIQNo transit routingOnly GeoCodingAllowedLowFully OSM Data packaged as API. Comes with only Geocoding data (no POI)
MapTilerGoodBasicClient-sideLow
HEREGoodBasic30 days or Response HeaderLowNo permanent storage of location IDs
MapQuestNo transit routingBasicRestrictive (non-paid)Low

POI Data: Image, Description, and Reviews Data

Apart from Google Maps Platform and ForeSquare, OSM-based GIS APIs only provide basic POI data. Some GIS APIs do not provide contact information or opening hours. We can integrate the following technologies to provide end-users with these data:

  • Image – For landmarks, well-known businesses (e.g. McDonalds), and attractions, use Wikipedia API to fetch images that are shareable for commercial purposes.
  • Description – For landmarks, well-known businesses (e.g. McDonalds), and attractions, use AI generated descriptions.
  • Contact, Hours, and Reviews – Use TripAdvisor or Yelp API to link review data, open hours, and contact information. Only load review data if the user clicks on it to limit unnecessary API calls. Yelp allows caching up to 24 hours but has no free tier.
  • In-House User-Contributed POI Data System – Support an in-house user-contributed POI Data system, where users can upload images, description, and reviews to a place.