All reviews of published articles are made public. This includes manuscript files, peer review comments, author rebuttals and revised materials. Note: This was optional for articles submitted before 13 February 2023.
Peer reviewers are encouraged (but not required) to provide their names to the authors when submitting their peer review. If they agree to provide their name, then their personal profile page will reflect a public acknowledgment that they performed a review (even if the article is rejected). If the article is accepted, then reviewers who provided their name will be associated with the article itself.
The reviewers are satisfied with the recent changes proposed by the authors, and therefore I can recommend this article for acceptance.
[# PeerJ Staff Note - this decision was reviewed and approved by Claudio Ardagna, a PeerJ Section Editor covering this Section #]
Clear flowcharts and experimental instructions.
The authors expanded the experimental sample.
The experimental results are credible.
The expanded samples (how to obtain them, whether they involve privacy, and how to measure distance) need to be explained in detail.
The previous experimental samples were seriously insufficient (only 16). After the authors expanded the samples, the experimental results are more convincing.
The authors addressed all issues.
-
-
**PeerJ Staff Note:** Please ensure that all review, editorial, and staff comments are addressed in a response letter and that any edits or clarifications mentioned in the letter are also inserted into the revised manuscript where appropriate.
**Language Note:** The review process has identified that the English language must be improved. PeerJ can provide language editing services - please contact us at [email protected] for pricing (be sure to provide your manuscript number and title). Alternatively, you should make your own arrangements to improve the language quality and provide details in your response letter. – PeerJ Staff
This paper presents a practical workflow for proximity queries using PostgreSQL’s PostGIS extension, applying spatial indexing and ST_DWithin/ST_Buffer functions, and demonstrates the approach on a small dataset of retail store locations. However, the methodology lacks novelty. My specific comments are as follows:
The inclusion of a workflow figure would greatly help readers understand the overall architecture and process steps.
The main technical content leverages well-documented PostGIS features (such as ST_DWithin, ST_Buffer, and spatial indexing) that are already widely applied in both academic and industrial settings. As such, the methods lack novelty.
The application scenario (retail store proximity search) is overly basic, and the experimental dataset is extremely limited (only 16 stores). With such a small and homogeneous case, the generalizability of the proposed workflow in diverse contexts remains unproven.
The solution does not consider spatial weights, distance decay, or more advanced spatial interaction models, which are crucial for more complex spatial analytics. Without addressing these gaps, it is unclear whether this approach is suitable in more challenging scenarios.
The paper does not sufficiently discuss new insights for industry or user experience. It would benefit from a deeper analysis of how the proposed method advances spatial querying or brings added value to real-world applications.
Language is generally clear and professional, though some encoding issues (e.g., “PostgreSQL9s” instead of “PostgreSQL’s”) should be fixed.
The introduction is brief and focused, but the literature review is very limited (only 5 references). Please add more recent and relevant studies, especially related to spatial queries with PostGIS.
Structure conforms to PeerJ standards. Figures are relevant and clearly described.
Raw data is provided (Walmart store locations in CSV), meeting transparency requirements.
This is a methodological implementation paper, appropriate for PeerJ’s scope.
The research goal is clear: demonstrating proximity queries using PostGIS and visualizing results via Google Maps.
Methods are well-documented and reproducible, with clear SQL examples.
Evaluation is minimal: only 16 data points and no performance benchmarks. Consider adding timing or scalability tests.
Results are sound and match expectations. The spatial queries return logical and correct results.
Visualizations support the findings well.
Conclusions are supported by the data but should be framed as a practical demonstration, not a generalizable performance study.
Strengths: Clear step-by-step methodology; Real-world dataset; Useful for education or prototype development.
Suggestions: Expand the literature review with recent GIS/spatial DB work; Add performance or scalability tests; Clarify that this is a demonstration study (not proposing new algorithms); Fix formatting and character issues; Add a short “Conclusion” section for completeness.
After reviewing the article, it is difficult to understand the main scientific goal of the work. The presented content does not introduce any new original ideas or a better solution to existing problems.
The article in its current form is not suitable for publication, and its improvement would likely be pointless. I recommend that the authors consider the following issues when writing a new version of the article:
1. The article lacks a literature review, despite the fact that there is a significant amount of work in the field of spatial queries. I believe that within the authors' specific topic, at least 30-40 articles can be found that solve the described problem in a more complex or well-thought-out manner.
2. There is also a lack of a discussion of the results, meaning a comparison of the obtained results with similar results from other researchers.
3. The main goal of the article is not clearly defined
4. The solution itself, based on searching for data objects by a given radius, is trivial and does not solve the fundamental problem of this type of task. Typically, one can move along roads from a central point, so location searching should consider the road network. Otherwise, a point within the given radius might be found, but the actual travel distance to reach it could be many times the radius (e.g., points on the other side of a river, highway, mountains, etc.). The best approach to solving this problem is network analysis, which is implemented in PostGIS.
5. Since the authors mention linking the database with visualization in Google Maps, they should have presented how this connection was made – there is not a word about it in the article.
6. In the case discussed by the authors, even the PostGIS extension is not necessary. The distance from a given point can be calculated based on the coordinates of the points themselves (lon, lat), which, when using a plain database and standard SQL, will be many times faster, and when using libraries such as Pandas, several hundred times faster.
The SQL query will be limited to two steps: calculating the distance between the given point and the data (Haversine formula) and selecting a group of results with the distance value of interest.
The solution presented by the authors only makes sense when searching for linear and polygonal objects with irregular shapes. However, even in this case, the query and the solution process itself do not contribute anything new to the problem of SQL queries.
8. The article does not present any results that can be compared with anything.
All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.