Report On Travel Pin

Travel Pin using MERN 01213702020 & 04013702020
Travel Pin using MERN
Submitted in partial fulfilment of the requirements

for the award of the degree of
Bachelor of Computer Applications

To
Guru Gobind Singh Indraprastha University, Delhi
Guide: Submitted by:

Dr. Ramandeep Kaur Anmol Tyagi
(Associate Professor) 01213702020
Manjesh Singh
04013702020
Institute of Information Technology & Management,

New Delhi – 110058
Batch (2020-2023)
Certificate
We, Anmol Tyagi 01213702020 and Manjesh Singh 04013702020 certify that
the Minor Project Report (BCA-357) entitled “Travel Pin using MERN” is
done by us and it is an authentic work carried out at Institute of Information
Technology & Management, Janakpuri. The matter embodied in this project
work has not been submitted earlier for the award of any degree or diploma to
the best of our knowledge and belief.
Signature of the Student: Signature of the Student:

Date:
Certified that the Project Report (BCA-357) entitled “Travel Pin using MERN”
done by the above student is completed under my guidance.
Signature of the Guide:

Date:
Name of the Guide: Dr. Ramandeep Kaur
Designation: Associate Professor
Countersigned Counter signed

Head of the Department Director
ACKNOWLEDGEMENT
The satisfaction of the successful completion of any task wouldn’t be complete without the expression
of gratitude to the people who made it possible. We express our deep sense of gratitude and
indebtedness to our guide Dr. Ramandeep Kaur for their keen interest, valuable guidance, constant
inspiration, and continuous encouragement during the various phases of work. We also express our
gratitude to all the faculty members of the IT department for their extended cooperation and creative
validation of our work as needed for its completion.
We cannot go without expressing our thanks to all the well-wishers for providing support and
cooperation during the preparation of the Report.
Name: Anmol Tyagi (01213702020)
Manjesh Singh (04013702020)

TABLE OF CONTENTS
S No Topic Page No
1. Certificate -
2. Acknowledgements -
3. List of Tables/Figures/Symbols -
4. Synopsis -
5. Chapter-1: System Introduction 1-4
6. 1.1 Description of System 1
7. 1.2 Data Collection 1
8. 1.3 Tools and Platform 2
9. 1.4 Project Planning 3
10. 1.5 Methodology 3
11. 1.5.1 SDLC Model 4
12. 1.5.2 Justification for the Selection of Model 4
13. Chapter-2: Systems Design 5-8
14. 2.1 Description of Information System (Block Diagram) 5
15. 2.1.1 Product Features 6
16. 2.1.2 Input/ Output Data elements 6
17. 2.2 Use Case Diagram 7
18. 2.3 Software Product constraints 8
19. Chapter-3: Systems Development & Implementation 9-13
20. 3.1 Program Development 9
21. 3.1.1 DFD level 0 9
22. 3.1.2 DFD level 1 10
23. 3.2 ER diagram 10
24. 3.3 Database specifications 11
25. 3.3.1 Database specification: Pin 11
26. 3.3.2 Database specification: User 12
27. 3.4 Validation specification 12-13
28. Chapter-4: Scope of Improvement, Summary & Conclusion 14-34
29. 4.1 Codes for the project 14-27
30. 4.2 Screenshots for the project 28-30
31. 4.3 Scope of the project 31
32. 4.4 Summary 32
33. 4.5 Conclusions 33
34. References 34
LIST OF TABLES
Table No Title Page No

2.1 Input/Output data elements 7
3.1 Database specification Pin 11
3.2 Database specification User 12
LIST OF FIGURES
Figure No Title Page No

1.1 Gantt Chart 3
1.2 Waterfall model 3
2.1 Block diagram for the user’s side 5
2.2 Block diagram for the guest’s side 5
2.3 Use case diagram 7
3.1 DFD level 0 9
3.2 DFD level 1 10
3.4 ER diagram 10
SYNOPSIS
1) TITLE OF PROJECT
Travel Pin using MERN
2) INTRODUCTION
A blog is a web page that you update on a regular basis. Oftentimes, brands have blogs right
on their websites, making it easier for users to find and engage with your posts. Within your
blog, you can share long-form articles that over topics your target audience may want to read
or learn about.
More often than not, a blog is written from the perspective of one person or a couple/small
group. Large companies are embedding blogs into their main website to explain
products/services in more detail and to attract internet traffic to their main website.
A travel blog is simply a blog where the entire focus is on the world of travel.
According to Killarney-based digital marketer, Anthony Keogh of Silicon Irish, “Once Google
opens the world of opportunities it gives anyone, anywhere a chance to write about their travel
experience online and with a little online marketing know-how, you could reach an audience
you couldn’t imagine you would”.
As travellers, we're always seeking to bring a slice of our adventures, experiences, and
ultimately our memories home. We do it by collecting things like magnets and pins, and we
also trinkets small and large to display proudly at home. One way of bringing the world home
is by putting up a large world map with pins as a great way to visualize everywhere that
you've been and everywhere that you still want to go.
With regular maps, you can't pin anything on it unless you're fine with a cluster of holes on
your wall. With the Scratch the World Travel Map, it's actually more difficult to scratch the
map cleanly and your kind of limited to scratching out countries as opposed to marking
somewhere specific or perhaps marking places differently based on where you've been and
where you want to go.
3) OBJECTIVE
The main objective of this project is to present a map-blog where multiple users will be able to
pin their visited places and also be able to check each other’s pinned locations, users can rate
the locations and even comment about it.
4) SCOPE
The scope of this project is to provide a common ground for travellers to come and encourage
travelling and blogging, showing their favourite places and the unseen wonders of the world
for everybody.
5) SRS Requirements
Use case diagram for Travel Pin
5.1. Functional Modules:
• User login/registration: Every user has to create an account into the system by
registering themselves. User can then log in and use the full functionality of the
system.
• View other pins: Every user can view the pinned location the map and details
regarding it.
• Creation of pins: Every registered user can mark his visited destinations with
a marker.
• Deletion of pins: Registered users can delete their respective pins from the map.
• Visibility of the pin: Although the pins are shown to every user, once the user
logs in the colour of their respective pin changes to different colour.
5.2. Non-Functional Modules:

5.2.1 Hashing of the password: The system automatically hashes the password
for security purposes and then again it is changed back while user logs in.
5.2.2 Automatically fetching the coordinates: System automatically fetches
the coordinates from the marked location.
5.2.3 Various Requirements:
• Reliability: The system will consistently perform its intended function. The
important information must be validated.
• Efficiency: Unnecessary data will not be transmitted on the network and database
server will be properly connected.
• Integrity: Guest user aren’t allowed to make any changes to the either the pin or the
user database.
• Security: Only registered users are able to make the changes. User’s password is
saved using hashing for security purposes.
• Maintainability: Backups for database are available.
• Design Constraints: This software provides security. The map prevents the system
from being misused by unauthorized users.
6) Tools and Platforms

6.1. Hardware Components:
▪ Hard Disk: - 500 GB
▪ Processor: INTEL CORE i5
▪ RAM: - 8 GB
6.2 Software Specifications:

▪ Operating System: - Windows
▪ Language used:
o Front end: - HTML, CSS, JavaScript, Material-Ui, Node js, Express, React
o Back end: - Mongo Db
7) Methodology:
7.1. Stage of Iterative Model:
• SDLC (Software Development Life Cycle)
SDLC processes generally number at 6 distinct stages: planning, analysis, designing,
development and testing, implementation, and maintenance. Each of them is briefly
explained below.
Phases of Life Cycle Model:
• Planning and requirement: All possible requirements of the system to be developed
are captured in this phase and documented in a requirement specification document.
• Analysis and design: The requirement specifications from first phase are studied in
this phase and system design is prepared. It helps in specifying hardware and system
requirements and also helps in defining overall system architecture.
• Implementation: With inputs from system design, the system is first developed in
small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality which is referred to as Unit Testing.
• Testing: All the units developed in the implementation phase are integrated into a
system after testing of each unit. Post integration the entire system is tested for any
faults and failures.
• Evaluation: This will evaluate the outcome of the processing whether the application
is running successfully or not.
Waterfall Model
Waterfall approach was first SDLC Model to be used widely in Software Engineering
to ensure success of the project. In "The Waterfall" approach, the whole process of
software development is divided into separate phases. In this Waterfall model,
typically, the outcome of one phase acts as the input for the next phase sequentially.
The following illustration is a representation of the different phases of the Waterfall
Model.
Waterfall Model
The sequential phases in Waterfall model are −
• Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification
document.
• System Design − The requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system
architecture.
• Implementation − With inputs from the system design, the system is first developed
in small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment. To fix
those issues, patches are released. Also, to enhance the product some better versions
are released. Maintenance is done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the defined
set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model".
In this model, phases do not overlap.
Waterfall Model - Application
Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of Waterfall model is
most appropriate are −
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.
7.2 Justification for choosing waterfall model:

▪ Works well for smaller projects where requirements are very well understood.
▪ So, by dividing the Project into small parts and implementing them makes easy
for us to make these applications needs and outcomes are clear.
▪ As we are new to this it is very difficult to analyse all requirements at once.
Building the whole application at once is not possible for us.
for us to make this application.
7.3 Advantages of this Model:
▪ An easy and transparent testing process as the test scenarios are already detailed in the
functional specification
▪ No “surprises” upon the completion
▪ Easy to understand as technical documentation is an essential aspect of the initial
requirements gathering stage
CHAPTER 1: Software Project Planning
1.1 Description of the Software System under Study:
As travellers, we're always seeking to bring a slice of our adventures, experiences, and ultimately
our memories home. We do it by collecting things like magnets and pins, and we also trinkets
small and large to display proudly at home. One way of bringing the world home is by putting
up a large world map with pins as a great way to visualize everywhere that you've been and
everywhere that you still want to go.
With regular maps, you can't pin anything on it unless you're fine with a cluster of holes on your
wall. With the Travel Pin one can gets a complete map to work on and pin the desired location.
The operations that are performed by this website are:
➢ Login/Sign Up: This website has a login page using which user can log in to the website to
make pins and delete them. The components of the Login/Sign Up module includes User
Name, Email, Password functionality.
➢ Add/Delete Pins: User can add or delete pins after logging in.
➢ Map: Shows the map for pinning the destination.
Types of Users Involved: -
There are basically two types of users involved. They are:
➢ User: The full functionality of the website is provided to the user like adding pins and
deleting them.
➢ Guest User: Guest user can only view the locations pinned by the other users and he/she
can’t change or edit them.
1.2 Data Collection:
The reference websites that are considered for the creation of this website are:
➢ GitHub-for creating and sharing the project among two (https://github.com/).

➢ Postman-for building and using the API’s.
➢ MongoDB-for connecting to the database(https://www.mongodb.com/).
➢ Material-UI-(https://mui.com/core/).
➢ Mapbox GL- for Map API (https://docs.mapbox.com/mapbox-gl-js/api/).
Modules selected for the study:
➢ Login/Sign Up Module: This module is used to sign up or log in to the website. This
module has a feature of signing up or logging in to the website. The components include in
this module are: User Name, Email, Password.
1
➢ CRUD Module: CRUD stands for Create, Read, Update, and Delete. In computer
programming, create, read, update, and delete (CRUD) are the four basic operations
of persistent storage. CRUD is also sometimes used to describe user interface conventions
that facilitate viewing, searching, and changing information using computer-
based forms and reports. This module is used for creating, reading, updating and deleting
the data. Admin is the one who is involved in all of these functions.
1.3 Tools/Platforms:
1.3.1 Hardware specifications
Processor INTEL CORE i5
RAM 8 GB
Hard Disk 500 TB
System Type 64-bit operating system, x-64based processor
Table No:1.1 Hardware specifications

1.3.2 Software specifications
Operating System Windows 10
Front End HTML, CSS, JavaScript, Material-UI, React, Mapbox GL
Back End MongoDB, Node js, Express
Table No:1.2 Software specifications
2
1.4 Project Planning:

The Project planning of the website is shown below in the form of Gantt chart:
Fig 1.1 Gantt Charts
1.5 Methodology:
1.5.1 SDLC Model to Be Used:
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software development
is divided into separate phases. In this Waterfall model, typically, the outcome of one phase
acts as the input for the next phase sequentially. The following illustration is a representation
of the different phases of the Waterfall Model.
Fig 1.2 Waterfall Model
3
The sequential phases in Waterfall model are −

• Requirement Gathering and analysis − All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification
document.
• System Design − The requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system
architecture.
• Implementation − With inputs from the system design, the system is first developed
in small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment. To fix
those issues, patches are released. Also, to enhance the product some better versions
are released. Maintenance is done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the defined
set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model".
In this model, phases do not overlap.
Waterfall Model - Application
Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of Waterfall model is
most appropriate are −
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.
1.5.2 JUSTIFICATION FOR CHOOSING WATERFALL MODEL:
▪ Works well for smaller projects where requirements are very well understood.
for us to make these applications
4
CHAPTER – 2: Software Requirement Specification
2.1 Description of Information System (Block Diagram):
With regular maps, you can't pin anything on it unless you're fine with a cluster of holes on your
wall. With the Travel Pin, one can pin their travels on the digital map and not worry about the
cluster and can also see other user’s pinned destination too.
Types of Users Involved under Study are:
There are basically two types of users involved. They are:

➢ User: The website has multiple users who are responsible for adding the pins, deleting
them.
➢ Guest User: Every user that is not registered is treated as a guest user and this user is only
allowed view the pins of every user on the map.
Fig 2.1 Block Diagram of the User’s side
Fig 2.2 Block Diagram of the Guest User’s side
5
2.1.1 Product Features:
The processes or modules that are involved in the information study are:
➢ Login/Sign Up: This website has a login/sign up page using which allows users to register
and unlocks the functionalities to them like pinning locations.
➢ Add/Delete: User can add pins or delete pins as long as they are logged in.
➢ Map: The website provides real working map where you can zoom and other functionalities
on the map.
➢ GPS: Shows the current location of the system and tracks it.
➢ Search a location: Users as well as guests can search for location on the map.
➢ Pin: The website allows registered user to pin the desired location on the map with a marker,
a single user can pin multiple locations.
2.1.2 Input/Output Data elements:
Input/Output Data Elements

Name
Login/Sign Up User Name, E-mail, Password.
Searching for the Location Name

Location
Adding the Pin Username, latitude, longitude, rating, description, creation date
and title.
Table No: 2.1 Input/Output data elements
6
2.2 Use Case Diagram:
Fig 2.3 Use Case Diagram for Travel Pin
2.2.1 Role of actors involved in the software under consideration:

➢ User: The main role of user is to add/delete the pins.
➢ Guest User: The main role of the guest user is to sign up into the website, if already has
an account the user can log in to the system and then he/she can make/ delete the pins.
2.2.2 Use Cases:
➢ Register: This use case describes how a particular actor signs up in the website. If the
use case is successful, the actor is registered into the system. If not, the system state is
unchanged.
Actors:
(i) User
(ii) Guest User
• System requests that the actor enter his/her Username, email ID and password for
registration.
• System validates the details and registers the user into the system as a user.
➢ Log IN: This use case allows the user to login into the system with the registered
credentials.
Actors: User
• System logs in the user if the validations are correct.
7
➢ Add/Delete Records: This use case allows the user to add or delete the pin of the
user/student.
Actors: User
• The system requests the user to specify the function, he/she would like to perform
(Add/Delete).
• One of the functions will execute after getting the information.
• If user double clicks on the map a new pin is generated.
• If user clicks on “Delete Records”, “Delete a record” sub flow will be executed.
➢ View Pins: This use case allows the user as well as guest user to view the pins.
Actors:
(i) User
(ii) Guest User
• The system shows already registered pins to everyone.
2.3 Software Product constraints:
➢ Version Compatibility: If the version of node js application is new, the website runs
smoothly but if the version is old, it sometimes gives an error. So basically, a compatible
version is very important for running the website.
➢ Browser Compatibility: This may be a forgotten variable, but you should remember that
browsers code differently. In the development of a website, cross browser compatibility is
very important, especially when you don’t know what browser target the user might be using.
The running of website may vary from browser to browser. So basically, a compatible
browser is most important for the user to log in to the website.
8
Chapter-3: Software Project Analysis

3.1 DFD Data flow Diagram (upto 1st level):
3.1.1 DFD level 0
Fig 3.1 DFD level 0
The above Context level or 0 level Data flow diagram shows the process of Travel Pin System
in which the particular user can request to sign up or login into the system and then system
checks the request and gives the response to the student. User can the pin their favorite locations
using the website. This helps multiple users to form a common community and show their visited
locations.
9
3.1.2 DFD level 1
Fig 3.2 DFD level 1

3.2 Entity-Relationship Diagram (ER-Diagram):
Fig 3.4 ER Diagram
An entity-relationship diagram model describes interrelated things of interest in a specific domain

of knowledge. A basic ER model is composed of entity types and specific relationships that exists
between the entities. In the diagram shown above User and Pin are the entities which have their
different attributes. User entity has attributes as User Name, Email, Password in which User Name
is a primary key (unique identity) and Pin entity has attributes as Description, Username, Latitude,
Longitude, Creation Date, Title, Rating. User and Pin have a “HAS A” relationship between them,
10
and the type of relationship they follow is 1 is to N that is One to many which means User can
have many Pins and many Pins will have only a one User related to it. So, in this way it follows
One to many relationships. Hence, they both, the entities and their attributes with the dataset, are
related to each other and form an association which bolsters the whole project and its operations.
In a way through this model, it clearly visualizes the whole project functioning and modelling.
3.3 Database Specifications:
FILE NAME: Pin.js
Field Name Field Field Type Size (No of Description

Code Characters)
User Name username String 20 Username of the user.
Title title String 10 Country name
Description desc String 10 Description
Rating rating Number 5 Rating of the location
Latitude lat Number 180 Latitude of the location

(-90 to 90)
Longitude long Number 360 Longitude of the location

(-180 to 180)
Table No:3.1 Database Specifications Pin
11
FILE NAME: User.js
Field Name Field Field Type Size (No of Description

Code Characters)
User Name username String 20 Username of the user.
Email email String 50 Email
Password password String 6 Password
Table No:3.2 Database Specifications User
3.4 Validations Specifications:
➢ Checking of the correct credentials during the login process.
➢ A data type check confirms that the data entered in the website has the correct data type.
12
➢ Longitude and Latitude must be within the respective boundaries.

Latitude: -90 to 90
Longitude: -180 to 180
➢ Rating should be less than or equal to 5.
➢ Only registered user can make the pins.
13
CHAPTER – 4: Scope of Improvement, Summary and

Conclusions
Codes for our Travel Pin website:
Front End
App.js
import 'mapbox-gl/dist/mapbox-gl.css'
import 'react-map-gl-geocoder/dist/mapbox-gl-geocoder.css'
import './App.css';
import StarIcon from '@mui/icons-material/Star';
import HowToRegIcon from '@mui/icons-material/HowToReg';
import LockOpenIcon from '@mui/icons-material/LockOpen';
import NearMeIcon from '@mui/icons-material/NearMe';
import LogoutIcon from '@mui/icons-material/Logout';
import DeleteIcon from '@mui/icons-material/Delete';
import * as React from 'react';
import Map, { Marker, Popup, NavigationControl, GeolocateControl } from 'react-map-gl';
import axios from 'axios';
import Register from './components/Register';
import Login from './components/Login';
import Error from './components/showError';
import ErrorLog from './components/showErrLog';
import Footer from './components/footer';
import { format } from 'timeago.js';
import AnchorIcon from '@mui/icons-material/Anchor';
import Geocoder from './components/geocoder';
const App = () => {

const myStorage = window.localStorage;
const [currentUser, setCurrentUser] = React.useState(myStorage.getItem('user'));
const [showRegister, setShowRegister] = React.useState(false);

const [showLogin, setShowLogin] = React.useState(false);
const [showError, setShowError] = React.useState(false);
const [showErrorLogin,setShowErrorLogin] = React.useState(false);
const [pins, setPins] = React.useState([]);
const [currentPlaceId, setCurrentPlaceId] = React.useState(null);
const [newPlace, setNewPlace] = React.useState(null);
14
const [title, setTitle] = React.useState(null);

const [desc, setDesc] = React.useState(null);
const [rating, setRating] = React.useState(0);
React.useEffect(() => {
axios.get("http://localhost:5000/api/pin").then((response) => {
setPins(response.data);
});
}, []);
const handleMarkerClick = (id) => {

setCurrentPlaceId(id);
};
const delPin = (id) => {

axios.delete(`http://localhost:5000/api/pin/${id}`);
window.location.reload(false);
}
const style = 'mapbox://styles/mapbox/streets-v12';
const handleAddClick = (e) => {

if (currentUser != null)
{
const [long, lat] = e.lngLat.toArray();
setNewPlace({
long,
lat,
})
}
else {setShowErrorLogin(true)}
//console.log(long,lat)
};
//console.log(newPlace);
const handleSubmit = async (e) => {

e.preventDefault()
const newPin = {
username: currentUser,
title: title,
desc: desc,
rating: rating,
lat: newPlace.lat,
long: newPlace.long,
}
//console.log(newPin)
15
if (newPin.username == null || title == null || desc== null || rating == null)

{
setShowError(true)
}
else {
try {
const res = await axios.post("http://localhost:5000/api/pin", newPin)
setPins([...pins,res.data])
setNewPlace(null);
window.location.reload(false);
} catch (err) {
console.log(err);
}
}
};
const delPinStyle = {
color:currentUser ? 'rgb(255, 146, 123)' : 'rgb(229, 228, 226)',
top: 10,
right:30,
position: 'absolute',
cursor: 'pointer',
}
const handleLogout = () => {

myStorage.removeItem("user");
setCurrentUser(null);
}
return <div>
<div className='navbar'>
<span className='title'>
<button className='buttonTitle'>Travel Pin<NearMeIcon color='secondary'
className='fly' sx={{ fontSize: 30 }}/></button>
</span>
{currentUser ?
(<>
<span>
<button className='button logoutbtn' onClick={handleLogout}>Log Out</button>
<LogoutIcon color={'warning'} className='logoutIcon'/>
</span>
<span>
16
<button className='button name'>Hello, {myStorage.getItem('user')}<AnchorIcon

className='nameIcon'/></button>
</span>
</>
):(
<>
<span>
<button className='button loginbtn' onClick={() =>
setShowLogin(true)}>Login</button><LockOpenIcon color='success'
className='loginIcon'/>
</span>
<span>
<button className='button regbtn' onClick={() =>
setShowRegister(true)}>Register<HowToRegIcon color='info'
className='regIcon'/></button>
</span>
</>
)}
</div>
<Map
initialViewState={{
latitude: 28.644800,
longitude: 77.216721,
zoom: 3,
doubleClickZoom: false,
pitch: 50,
}}
style={{width: '100vw', height: '100vh'}}
mapStyle= {style}
mapboxAccessToken={process.env.REACT_APP_MAPBOX_TOKEN}
onDblClick={handleAddClick}
>
{pins.map((mark) => {
return <div>
<Marker longitude={mark.long} latitude={mark.lat} anchor="bottom"
style={{cursor:'pointer'}}
onClick={() => handleMarkerClick(mark._id)}
>
<svg
width="25" height="25"
stroke={mark.username === currentUser ? "rgb(255, 66, 0)" : "rgb(131, 0, 186)"}
strokeWidth={"2"}
fill="none" strokeLinecap={"round"}
strokeLinejoin={"round"}><path d="M21 10c0 7-9 13-9 13s-9-6-9-13a9 9 0 0 1 18
0z"></path><circle cx="12" cy="10" r="3"></circle></svg>
</Marker>
17
{
mark._id === currentPlaceId && (
<Popup longitude={mark.long} latitude={mark.lat}
anchor="top"
closeButton={true}
closeOnClick={false}
closeOnMove={true}
onClose={() => setCurrentPlaceId(null)}>
<div className='card'>
<label className='di'>Place:</label>
<h4 className='place'>{mark.title}</h4>
<label className='di'>Review</label>
<p className='desc'>{mark.desc}</p>
<label className='di'>Rating</label>
<div className='stars'>
{Array(mark.rating).fill(<StarIcon className='star'/>)}
</div>
<label className='di'>Information</label>
<span className='username'>Created by: <b>{mark.username}</b></span>
<span className='date'>Created {format(mark.createdAt)}</span>
<DeleteIcon style={delPinStyle} sx={{ fontSize: 25 }} onClick={mark.username ===
currentUser ? () => delPin(mark._id) : null}/>
</div>
</Popup>
)
}
</div>
})
}
{ newPlace &&
(<Popup longitude={newPlace.long} latitude={newPlace.lat}
anchor="top"
closeButton={true}
closeOnClick={false}
maxWidth= 'none'
closeOnMove={false}
onClose={() => setNewPlace(null)}>
<div>
<>
<form onSubmit={handleSubmit}>
<label className='pform'>Title</label>
<input
placeholder='Enter a title'
onChange={(pformf) => setTitle(pformf.target.value)} />
<label className='pform'>Review</label>
<textarea
18
placeholder='Say something about this place'

onChange={(pformf) => setDesc(pformf.target.value)}/>
<label className='pform'>Rating</label>
<select onChange={(pformf) => setRating(pformf.target.value)}>
<option value={1}>1</option>
</select>
<button className='submitButton' type="submit">Add Pin</button>
</form>
</>
</div>
</Popup>
)
}
{showRegister &&
<Register setShowRegister = {setShowRegister} />
}
{showLogin &&
<Login setShowLogin = {setShowLogin} myStorage = {myStorage} setCurrentUser =
{setCurrentUser}/>
}
{ showError &&
<Error setShowError={setShowError}/>
}
{ showErrorLogin &&
<ErrorLog setShowErrorLogin={setShowErrorLogin}/>
}
<Geocoder/>
<GeolocateControl trackUserLocation={true} showAccuracyCircle={true}
showUserHeading={true} />
<NavigationControl />
<Footer />
</Map>
</div>
}
export default App;
19
Components:
• Register:
import './register.css';
import AddLocationAltIcon from '@mui/icons-material/AddLocationAlt';
import ClearIcon from '@mui/icons-material/Clear';
import { useRef, useState } from 'react';
export default function Register({setShowRegister}) {

const [success, setSuccess ] = useState(false);
const [error, setError] = useState(false);
const nameRef = useRef();

const emailRef = useRef();
const passRef = useRef();

e.preventDefault();
const newUser = {
username: nameRef.current.value,
email: emailRef.current.value,
password: passRef.current.value,
};
try {
await axios.post('http://localhost:5000/api/users/reg',newUser)
setError(false)
setSuccess(true)
} catch (err) {
setError(true);
}
};
return (
<div className='registerContainer'>
<div className='reglogo'>
<AddLocationAltIcon sx={{ fontSize: 40 }}/>
Register
</div>
<input type="text" placeholder='Username' ref={nameRef}/>
<input type="text" placeholder='Email' ref={emailRef}/>
<input type="password" placeholder='Password' ref={passRef}/>
<button className='registerButton'>Register</button>
{success &&
<span className='success'>You can login now!</span>
20
} {error &&
<span className='failure'>Something went wrong!</span>
}
</form>
<ClearIcon className='regCancel' onClick={() => setShowRegister(false)}/>
</div>
)
}
• LogIn:
import './login.css';
import EditLocationAltIcon from '@mui/icons-material/EditLocationAlt';
import ClearIcon from '@mui/icons-material/Clear';
import { useRef, useState } from 'react';
export default function Login({setShowLogin, myStorage, setCurrentUser}) {
const [error, setError] = useState(false);
const nameRef = useRef();

const passRef = useRef();

e.preventDefault();
const user = {
username: nameRef.current.value,
password: passRef.current.value,
};
try {
const res = await axios.post('http://localhost:5000/api/users/login',user)
myStorage.setItem("user",res.data.username)
setCurrentUser(res.data.username)
setShowLogin(false)
setError(false)
} catch (err) {
setError(true);
}
};
return (
<div className='loginContainer'>
<div className='loglogo'>
<EditLocationAltIcon sx={{ fontSize: 40 }}/>
Log In
</div>
21
<input type="text" placeholder='Username' ref={nameRef}/>
<input type="password" placeholder='Password' ref={passRef}/>
<button className='loginButton'>Login</button>
{error &&
<span className='failure'>Something went wrong!</span>
}
</form>
<ClearIcon className='loginCancel' onClick={() => setShowLogin(false)}/>
</div>
)
}
• Show Error Log

import './showErrLog.css'
import NearbyErrorIcon from '@mui/icons-material/NearbyError';
export default function showErrorLogin({setShowErrorLogin}) {
return (<div className='errorLog'>

<div className='allogo' >
<NearbyErrorIcon sx={{ fontSize: 40 }}/>Travel Pin
</div>
<span className='errMes'>
Please login to pin your travels.
</span>
<button className='errBtn' onClick={() =>
setShowErrorLogin(false)}>OK</button>
</div>
)
}
• Show Error
import './showErr.css'
import ErrorIcon from '@mui/icons-material/Error';
export default function showError({setShowError}) {
return (<div className='errorCom'>

<div className='errlogo' >
<ErrorIcon sx={{ fontSize: 40 }}/>Travel Pin
</div>
<span className='errMessage'>
Please enter the details then submit the form, empty pins aren't allowed.
</span>
<button className='errButton' onClick={() =>
setShowError(false)}>OK</button>
22
</div>
)
}
• Geo Coder
import MapBoxGeocoder from '@mapbox/mapbox-gl-geocoder';
import { useControl } from 'react-map-gl'
import mapboxgl from 'mapbox-gl'
import '@mapbox/mapbox-gl-geocoder/dist/mapbox-gl-geocoder.css'
import './geocoder.css'
const geocoder = () => {
const ctrl = new MapBoxGeocoder({
accessToken: process.env.REACT_APP_MAPBOX_TOKEN,
mapboxgl: mapboxgl,
marker:{
color: "#FFC300",
},
collapsed:false,
})
// eslint-disable-next-line react-hooks/rules-of-hooks
useControl(() => ctrl)
return (
null
)
}
export default geocoder
Back End
• Index.js
const express = require('express');
const mongoose = require('mongoose');
const cors = require('cors');
const pinRoute = require('./routes/pins')
const userRoute = require('./routes/users')
const app = express();
require('dotenv').config();
app.use(express.json());
app.use(cors());
mongoose.connect(process.env.CONNECTION_URL, {useNewUrlParser: true}).then(()

=> {
console.log("MongoDB Connected")
}).catch(err => console.log(err));
23
//using of routes
app.use('/api/users', userRoute);
app.use('/api/pin', pinRoute);
PORT = process.env.PORT
app.listen(PORT, () => {
console.log(`Server is running at http://localhost:${PORT}`);
})
• Routes
▪ Pins
const router = require('express').Router();
const Pin = require('../models/Pin')
//create Pin
router.post("/",async (req, res) => {
const newPin = new Pin(req.body)
try {
const savedPin = await newPin.save();
res.status(200).json(savedPin);
} catch (err) {
res.status(500).json(err);
}
});
//get pins
router.get("/", async (req, res) => {
try {
const pins = await Pin.find();
res.status(200).json(pins);
} catch (err) {
}
})
router.delete("/:id", async (req, res) => {

const id = req.params.id;
//console.log(id)
try {
await Pin.findByIdAndRemove(id).exec();
res.status(200)
} catch (err) {
res.status(500).json(err)
//console.log("Error")
}
})
module.exports = router;
24
▪ Users
const router = require('express').Router();
const User = require('../models/User');
const bcrypt = require("bcrypt");
//register
router.post("/reg", async (req, res) => {
try {
//make password
const salt = await bcrypt.genSalt(10);
const hashedPassword = await bcrypt.hash(req.body.password, salt);
//create user
const newUser = new User({
username: req.body.username,
email: req.body.email,
password: hashedPassword,
})
//save
const user = await newUser.save();
res.status(200).json(user._id);
} catch (err) {
}
})
//login
router.post("/login", async (req, res) => {
try {
//find user
const foundUser = await User.findOne({ username: req.body.username });
//console.log({ foundUser })
if (foundUser) {
//if foundUser: compare entered password to stored/foundUser password.
const validPassword = await bcrypt.compare(
req.body.password,
foundUser.password
);
if (validPassword) {
//if both passwords match:
res.status(200).json({ username: foundUser.username });
} else {
//if both passwords dont match:
res.status(400).json({err: "Incorrect username or password" });
}
} else {
//if !foundUser:
25
res.status(400).json({err: "Incorrect username or password" });

}
} catch (err) {
}
});
module.exports = router;
• Models
▪ Pins
const { Schema } = mongoose;
const requiredNumber = {
type: Number,
required: true,
};
const userPin = new Schema({

username: {
type: String,
require: true,
},
title: {
type: String,
require: true,
},
desc: String,
rating: {
type: Number,
min: 0,
max: 5,
default: 0,
},
lat: {
type: Number,
require: true,
min: -90,
max: 90,
},
long: {
type: Number,
require: true,
min: -180,
max: 180,
},
26
}, {
timestamps: true,
});
module.exports = mongoose.model('Pin',userPin);
▪ Users
const { Schema } = mongoose;
const userSchema = new Schema({

username: {
type:String,
require: true,
min: 3,
max: 20,
unique: true,
},
email: {
type:String,
require: true,
max: 50,
unique: true,
},
password: {
type:String,
require: true,
min: 6,
},
}, {timestamps: true})
module.exports = mongoose.model('Users',userSchema);
27
Screen Shots from the web-application:
28
29
30
FUTURE SCOPE OF THE PROJECT
The purpose of any new technology is to make people life easier. This project is aimed at developing
Travel Pin System for all the travelers and provides a website for tracking of all their travel logs till
now. The objective of making this website is that each and every traveler can maintain a track of
their destination. In future we will add the features that will make the experience more enriching,
we will also see the entire system more interactive with more functionalities. In short travelers will
be able to enjoy more
31
SUMMARY
A travel log System is a website that offers the provisions to the travellers like looking locations
and pinning their destinations. The website provides a very unique way of looking up destinations
and pinning them. There are two types of users involved, guest and user, guest has almost no
authority but can still look up the other pins and search for the location where as user has much
control over the site such as creating and deleting the pins and rating them.
The processor used in making this project is INTEL CORE i5 and the system type is 64-bit windows
operating system. The Front end technology includes: HTML, CSS, Material UI, Node js, Express,
React etc. The Back end technology used here is Mongo DB. There are two modules which are
selected under this study. First one is the login and sign up module which is used to logging in to
the system. Second one is the CRUD module which is used to add, delete or update. The constraints
faced in making this project is the version compatibility and the browser compatibility. The SDLC
Model used in making this project is the Waterfall Model because this model is best suited for the
small projects, it is easy to understand and use, each phase has specific deliverables and a review
process, phases are processed and completed one at a time etc.
The main reason for choosing the waterfall model is that as we are new to this so it is very difficult
for us to analyse all the requirements at once. Building the whole web application in one go is not
possible for us, so by dividing the project into the small parts and implementing them makes it very
easy for us to make this web app.
32
CONCLUSION
➢ Travel Pin provides an interactive option for users to pin their destinations and look up at other
locations too.
➢ Creates a safe environment for travellers to engage with one another using pins.
➢ User’s data is safe as only registered user can alter the pins.
➢ It offers the simplicity of fast and clickable service to all the travellers.
33
References
➢ https://www.tutorialspoint.com/sdlc/sdlc_quick_guide.htm
➢ https://mui.com/material-ui/icons/
➢ https://docs.mapbox.com/mapbox-gl-js/api/
➢ https://github.com/mapbox/mapbox-gl-js
➢ https://www.postman.com/
34

Report On Travel Pin

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Report On Travel Pin

Uploaded by

Copyright:

Available Formats

Travel Pin using MERN 01213702020 & 04013702020

Travel Pin using MERN

Submitted in partial fulfilment of the requirements

Bachelor of Computer Applications

Guide: Submitted by:

Institute of Information Technology & Management,

Signature of the Student: Signature of the Student:

Signature of the Guide:

Countersigned Counter signed

validation of our work as needed for its completion.

cooperation during the preparation of the Report.

Name: Anmol Tyagi (01213702020)

Manjesh Singh (04013702020)

Table No Title Page No

Figure No Title Page No

Use case diagram for Travel Pin

5.1. Functional Modules:

5.2. Non-Functional Modules:

6) Tools and Platforms

6.2 Software Specifications:

7.2 Justification for choosing waterfall model:

7.3 Advantages of this Model:

The operations that are performed by this website are:

Types of Users Involved: -

There are basically two types of users involved. They are:

1.2 Data Collection:

➢ GitHub-for creating and sharing the project among two (https://github.com/).

Modules selected for the study:

1.3.1 Hardware specifications

Processor INTEL CORE i5

Hard Disk 500 TB

System Type 64-bit operating system, x-64based processor

Table No:1.1 Hardware specifications

Operating System Windows 10

Front End HTML, CSS, JavaScript, Material-UI, React, Mapbox GL

Back End MongoDB, Node js, Express

Table No:1.2 Software specifications

1.4 Project Planning:

Fig 1.1 Gantt Charts

Fig 1.2 Waterfall Model

The sequential phases in Waterfall model are −

CHAPTER – 2: Software Requirement Specification

2.1 Description of Information System (Block Diagram):

There are basically two types of users involved. They are:

Fig 2.1 Block Diagram of the User’s side

Fig 2.2 Block Diagram of the Guest User’s side

2.1.1 Product Features:

2.1.2 Input/Output Data elements:

Input/Output Data Elements

Login/Sign Up User Name, E-mail, Password.

Searching for the Location Name

Table No: 2.1 Input/Output data elements

2.2 Use Case Diagram:

Fig 2.3 Use Case Diagram for Travel Pin

2.2.1 Role of actors involved in the software under consideration:

2.2.2 Use Cases:

• System logs in the user if the validations are correct.

• One of the functions will execute after getting the information.

• If user double clicks on the map a new pin is generated.

• The system shows already registered pins to everyone.

2.3 Software Product constraints:

Chapter-3: Software Project Analysis

3.1.1 DFD level 0